No description available.

Made available in DSpace on 2014-11-10T11:09:41Z (GMT). No. of bitstreams: 0 Previous issue date: 2013-08-07Bitstream added on 2014-11-10T11:58:47Z : No. of bitstreams: 1 000787445.pdf: 974406 bytes, checksum: 3e701ceadf5e053926fd1e9cf1e9e039 (MD5) / Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (CAPES) / Devido a queda gradual no custo de aquisição de novos computadores, há cada vez mais dispositivos computacionais adentrando o mercado. A grande quantidade de novos dispositivos gera heterogeneidade entre eles e esta dificulta a administração de ambientes computacionais, pois é necessário manter os sistemas funcionando em compatibilidade com dispositivos bastante distintos simultaneamente. O sistema WSE-OS propõe uma solução de centralização de dados e recursos que aborda o problema da heterogeneidade de maneira eficaz. Fazendo uso da tecnologia wireless a ferramenta WSE-OS utiliza uma estrutura Thin Client que permite aos seus clientes executarem instanciações de sistemas operacionais virtualizados armazenados no servidor. Este trabalho apresenta uma proposta que altera a estrutura do WSE-OS incluindo a capacidade de operar com múltiplos servidores, tendo como objetivo aumentar a escalabilidade, disponibilidade e confiabilidade da ferramenta por meio de técnicas de replicação do servidor e escalonamento das conexões. A replicação de dados consiste em detectar as alterações sofridas nos dados contidos em um determinado servidor e transmiti-las aos demais priorizando a consistência entre as réplicas. O escalonamento de conexões funciona ativamente distribuindo os clientes dentre os servidores para melhorar o desempenho da ferramenta / Due to a gradual decrease in the cost of purchasing new computers, there is more and more computing devices entering the market. The large quantity of new devices creates heterogeneity among them and this complicates the administration of computing environments, because is necessary to keep the systems running in compatibility with quite different devices simultaneously. The WSE-OS system proposes a solution for centralizing data and resources that addresses this problem effectively. Using wireless networking technology, the WSE-OS tool uses a Thin Client structure that allows its clients to execute instantiations of virtualized operating systems stored on the server. This paper presents a proposal that changes WSE-OS's structure including the ability to run with multiple servers, having as its goal increase scalability, availability and reliability through server’s data replication and staggering of connections. Data replication consists in detecting changes on data from a given server and transmit it to the others prioritizing the consistency among replicas. The staggering of connections works on actively distributing the clients among servers to improve system’s performance

O presente trabalho realiza uma validação experimental, através da técnica de injeção de falhas por software, de sistemas de informações que utilizam gerenciadores de banco de dados distribuídos comerciais. Estes experimentos visam a obtenção de medidas da dependabilidade do SGBD utilizado, levantamento do custo de seus mecanismos de tolerância a falhas e a real aplicabilidade de SGBDs comerciais em sistemas de missão crítica. Procurou-se avaliar e validar as ferramentas de injeção de falhas utilizadas, no caso específico deste trabalho a ComFIRM e o FIDe. Inicialmente são introduzidos e reforçados os conceitos básicos sobre o tema, que serão utilizados no decorrer do trabalho. Em seguida são apresentadas algumas ferramentas de injeção de falhas em sistemas distribuídos, bem como os modelos de falhas em banco de dados distribuídos. São analisados alguns estudos de aplicação de ferramentas de injeção de falhas em bancos de dados distribuídos. Concluída a revisão bibliográfica é apresentado o modelo de software e hardware que foi implementado, destacando o gerador de cargas de trabalho GerPro-TPC e o gerenciador de injeções e resultados GIR. O GerPro-TPC segue as especificações TPC-c para a simulação de um ambiente transacional comercial padrão e o GIR realiza a integração das ferramentas de injeção de falhas utilizadas, bem como a elaboração do cenário de falhas a injetar e a coleta dos resultados das falhas injetadas. Finalmente são descritos os experimentos realizados sobre o SGBD PROGRESS. São realizados 361 testes de injeções de falhas com aproximadamente 43.000 falhas injetadas em experimentos distintos. Utiliza-se dois modelos de falhas: um focado em falhas de comunicação e outro em falhas de hardware. Os erros resultantes das falhas injetadas foram classificados em erros ignorados/mascarados, erros leves, erros graves e erros catastróficos. Dos modelos de falhas utilizados as que mais comprometeram a dependabilidade do SGBD foram as falhas de hardware. As falhas de comunicação somente comprometeram a disponibilidade do sistema alvo.

O estudo e desenvolvimento de sistemas distribuídos é uma tarefa que demanda grande esforço e recursos. Por este motivo, a pesquisa em sistemas deste tipo pode ser auxiliada com o uso de simuladores, bem como por meio da emulação. A vantagem de se usar simuladores é que eles permitem obter resultados bastante satisfatórios sem causar impactos indesejados no mundo real e, conseqüentemente, evitando desperdícios de recursos. Além disto, testes em larga escala podem ser controlados e reproduzidos. Neste sentido, vem sendo desenvolvido desde 2000 um framework para simulação de algoritmos distribuídos denominado Neko. Por meio deste framework, algoritmos podem ser simulados em uma única máquina ou executados em uma rede real utilizando-se o mesmo código nos dois casos. Entretanto, através de um estudo realizado sobre os modelos de defeitos mais utilizados na literatura, verificou-se que o Neko é ainda bastante restrito nesta área. A única classe de defeito abordada, lá referida como colapso, permite apenas o bloqueio temporário de mensagens do processo. Assim, foram definidos mecanismos para a simulação das seguintes classes de defeitos: omissão de mensagens, colapso de processo, e alguns defeitos de rede tais como quebra de enlace, perda de mensagens e particionamento. A implementação foi feita em Java e as alterações necessárias no Neko estão documentadas no texto. Para dar suporte aos mecanismos de simulação de defeitos, foram feitas alterações no código fonte de algumas classes do framework, o que exige que a versão original seja alterada para utilizar as soluções. No entanto, qualquer aplicação desenvolvida anteriormente para a versão original poderá ser executada normalmente independente das modificações efetuadas. Para testar e validar as propostas e soluções desenvolvidas foram utilizados estudos de caso. Por fim, para facilitar o uso do Neko foi gerado um documento contendo informações sobre instalação, configuração e principais mecanismos disponíveis no simulador, incluindo o suporte a simulação de defeitos desenvolvido neste trabalho. / The study and development of distributed systems is a task that demands great effort and resources. For this reason, the research in systems of this type can be assisted by the use of simulators, as well as by means of the emulation. The advantage of using simulators is that, in general, they allow to get acceptable results without causing harming impacts in the real world and, consequently, preventing wastefulness of resources. Moreover, tests on a large scale can be controlled and reproduced. In this way, since 2000, a framework for the simulation of distributed algorithms called Neko has been developed. By means of this framework, algorithms can be simulated in a single machine or executed in a real network, using the same code in both cases. However, studying the most known and used failure models developed having in mind distributed systems, we realized that the support offered by Neko for failure simulation was too restrictive. The only developed failure class, originally named crash, allowed only a temporary blocking of process’ messages. Thus, mechanisms for the simulation of the following failure classes were defined in the present work: omission of messages, crash of processes, and some network failures such as link crash, message drop and partitioning. The implementation was developed in Java and the necessary modifications in Neko are registered in this text. To give support to the mechanisms for failure simulation, some changes were carried out in the source code of some classes of the framework, what means that the original version should be modified to use the proposed solutions. However, all legacy applications, developed for the original Neko version, keep whole compatibility and can be executed without being affected by the new changes. In this research, some case studies were used to test and validate the new failure classes. Finally, with the aim to facilitate the use of Neko, a document about the simulator, with information on how to install, to configure, the main available mechanisms and also on the developed support for failure simulation, was produced.

Com a disponibilidade de redes que ligam estações cada vez mais poderosas a baixos custos, o interesse em torno de ferramentas que suportam a programação paralela em arquiteturas deste tipo tem aumentado significativamente. Esta dissertação trata do projeto e implementação de YALI (Yet Another Linda Implementation), uma ferramenta destinada ao desenvolvimento e execução de programas paralelos em redes heterogêneas de computadores. Com o objetivo de oferecer uma interface simples e flexível para os usuários programadores, YALI baseia-se no modelo Linda[GEL85], que destaca-se por utilizar uma abstração de alto nível para a cooperação entre processos. Em Linda, processos interagem por intermédio de uma memória associativa logicamente compartilhada, denominada Espaço de Tuplas. Entre outras vantagens deste modelo pode-se citar a simplicidade de suas primitivas e a possibilidade de incorporá-las a uma linguagem seqüencial conhecida, o que contribui fortemente para sua fácil assimilação, mesmo por usuários com pouca experiência em programação paralela. Após uma descrição detalhada do modelo Linda, este trabalho discute varias questões envolvidas no projeto e implementação de sistemas nele baseados. Para oferecer uma visão pratica das soluções mais freqüentemente adotadas para estas questões, quatro sistemas que implementam o modelo para programação paralela em redes são apresentados e avaliados. São eles: Glenda, uma implementacao do modelo baseada na ferramenta PVM (Parallel Virtual Machine); POSYBL (PrOgramming SYstem for distriButed appLications), um sistema construído através de recursos de sistemas operacionais compatíveis com Unix; p4-Linda, construído a partir da ferramenta de programação paralela p4 e, por fim, Network-Linda, uma implementação comercial do modelo. Depois do estudo dos quatro sistemas acima, o projeto de YALI e discutido detalhadamente. Decidiu-se, inicialmente, que YALI deveria incorporar o modelo Linda a linguagem C, que é largamente utilizada no desenvolvimento de programas de propósito geral. Além disso, optou-se por estender o modelo com algumas novas primitivas, de modo a oferecer maior poder de expressão ao usuário. Basicamente, as primitivas que YALI acrescenta ao modelo servem para dar suporte a operações globais e a criação dinâmica de threads. Operações globais servem para expressar a comunicação e a sincronização entre múltiplos processos, sendo utilizadas com bastante freqüência em vários tipos de programas paralelos. YALI suporta operações globais de maneira totalmente ortogonal ao modelo Linda, garantindo melhor desempenho sem afetar o nível de abstração oferecido. o suporte a criação dinâmica de threads, por outro lado, tem o objetivo de permitir a exploração de um paralelismo de granularidade fina, adequado ate mesmo a execução de rotinas simples em paralelo. Para suportar o desenvolvimento e execução de aplicações paralelas, YALI e implementado através de três componentes distintos. O primeiro e um pré-processador, que garante uma interface simplificada com o usuário. 0 segundo e uma biblioteca, que contem as rotinas de suporte as primitivas YALI e deve ser ligada aos programas de usuários. O terceiro componente, por fim, e um utilitário destinado a controlar a inicialização e o termino de aplicações paralelas, que baseia-se em uma configuração estabelecida pelo usuário para distribuir processos sobre uma rede de computadores. Ao contrário da maioria dos sistemas baseados em Linda, YALI implementa um espaço de tuplas distribuído entre os processos que compõem uma aplicação paralela, dispensando o use de processos especializados no gerenciamento de tuplas. Para isso, YALI utiliza múltiplas threads em cada processo definido pelo usuário, e distribui tuplas sobre estes processos através de um mecanismo baseado em hashing. A implementação de YALI leva em conta a heterogeneidade inerente a ambientes de rede, permitindo que maquinas com diferentes arquiteturas e sistemas operacionais sejam utilizadas na execução de programas paralelos. Por fim, YALI é totalmente implementado a partir de recursos presentes em sistemas compatíveis com Unix, de modo a aumentar sua portabilidade e garantir sua eficiência. / With the availability of networks connecting powerful workstations at a low cost, increasing interest has been devoted to systems that support parallel programming in such architectures. This document describes the design and implementation of YALI (Yet Another Linda Implementation), a tool that allows the development and execution of parallel programs in heterogeneous computer networks. Aiming to provide a simple and flexible interface for its users, YALI is based on the Linda parallel programming model[GEL85], that outstands in providing a high level abstraction for cooperation between processes. In Linda, communication and synchronization take place through an associative, logically shared memory called Tuple Space. Among the advantages of this model, one can mention the simplicity of its primitives, and the possibility of incorporate them in a well-known sequential language. These characteristics make Linda easy to learn, even to users with little experience in parallel programming. After a detailed description of the Linda model, this document discusses some design and implementation issues related to Linda-based systems. In order to provide a practical view of some usual solutions to address these issues, four Linda-based systems are presented and evaluated. These systems are: Glenda, an implementation of Linda built on top of PVM (Parallel Virtual Machine); POSYBL (PrOgramming SYstem for distriButed appLications), that relies on features provided by Unix-like operating systems to implement the model; p4-Linda, built on top of p4 parallel programming tool and, at last, Network-Linda, a comercial product based on Linda. All these systems, as YALI, are specially tailored to parallel programming in computer networks. Following the study of the four systems, this documents presents the design of the YALI system. One of the first design decisions was to incorporate the Linda primitives to the C language, that is broadly used as a general purpose programming language. In addition, a set of new primitives was designed as an extension to the original model, in order to increase YALI's expressivenes. Basically, the new primitives support global operations and dynamic thread creation. Global operations are useful to express communication and synchronization among multiple processes, and are frequently used many classes of parallel programs. YALI gives support to global operations in a way that is totally ortoghonal to the Linda model, ensuring better performance without affecting the abstraction level inherent to Linda-based systems. The support to dynamic thread creation, on the other hand, is helpful to explore lightweight parallelism, which allows the execution of simple routines in parallel. To support the development and execution of parallel applications, YALI is made up of three distinct components. The first is a pre-processor, that provides a simple user interface. The second is a library, that must be linked to the user programs since it's where YALI primitives are actuall y implemented. Finally, the third component is an utility that controls initialization and termination of parallel applications, which takes configuration parameters from the user to distribute processes over a newtork. In contrast with most Linda-based systems, YALI relies on a tuple space that is distributed among the processes in the same parallel application, so that intermediate tuple managers are not necessary To implement that, multiple threads are embedded in each user process, and tuples are spread over the processes in the basis of a hashing mechanism. YALI's implementation takes in account the inherent heterogeneity of network environments, allowing machines with different architectures and operating systems to be used in the execution of parallel programs. Finally, YALI is build on top of common features of Unix-like operating systems, in order to increase its efficiency and portability.

O advento dos computadores pessoais e posteriormente das estações de trabalho, somado ao desenvolvimento de hardware de comunicação eficiente e de baixo custo, levou a popularização das redes locais. Entretanto, o software não presenciou o mesmo desenvolvimento do hardware, especialmente devido a complexidade dos sistemas distribuídos. A heterogeneidade das máquinas, sistemas e redes, inerente aos ambientes computacionais modernos, restringe igualmente a integração e cooperação entre os nodos disponíveis. 0 objetivo do presente trabalho é, a partir da análise dos principais aspectos relacionados à distribuição e à heterogeneidade, desenvolver um sistema operacional de rede heterogêneo. Tal sistema, denominado HetNOS (de Heterogeneous Network Operating System), permite o desenvolvimento e validação de aplicações distribuídas homogêneas e heterogêneas de forma rápida e fácil. Os usuários podem concentrar-se nos aspectos de distribuição dos algoritmos, abstraindo detalhes dos mecanismos de comunicação, pois a programação de aplicações distribuídas é baseada em uma plataforma de interface homogênea, fácil de usar e com independência de localidade. Sendo um sistema operacional de rede, o HetNOS atua sobre o conjunto de sistemas operacionais nativos existentes; o ambiente de trabalho e estendido e não substituído. Não há entidades nem informações centralizadas, e os algoritmos são distribuídos, usualmente resultando maior confiabilidade e desempenho. A topologia do sistema é um anel lógico, esquema justificado pela generalidade de tal configuração e pela simplificação do projeto do núcleo distribuído do HetNOS. O paradigma de comunicação entre módulos e a troca de mensagens, mecanismo implementado sobre a interface de programação em rede sockets. Não há compartilhamento de memória em nenhuma instância, tornando o sistema mais legível, manutenível e portável. A interpelação entre módulos fica restrita à interface de mensagens definidas e aceitas por cada módulo. A arquitetura do HetNOS é estruturada e distribuída, pois o sistema é composto de camadas hierárquicas subdivididas em módulos, estes implementados com processos. O nível 1 corresponde ao conjunto de núcleos de sistemas operacionais nativos suportados, sobre o qual é implementado o núcleo distribuído heterogêneo do HetNOS, a DCL (Distributed Computing Layer). O principal serviço fornecido pela DCL (executada no nível 2), é um subsistema de troca de mensagens canônico e independente de localidade. Processos servidores e de usuários podem utilizar as mais variadas formas de comunicação por mensagens, tal como envio, recepção e propagação de mensagens síncronas, assíncronas, bloqueantes e não bloqueantes. No nível 3 estão os servidores do sistema, que estendem e implementam de forma distribuída a funcionalidade do sistema nativo. O Servidor de Nomes é o repositório global de dados, servindo a processos do sistema e de usuários. O Servidor de Autorização implementa o esquema de controle no acesso a recursos do sistema. O Servidor de Tipos permite que aplicações copiem dados estruturados de forma independente de localidade e de arquitetura. Por fim, o Servidor de Arquivos estende os serviços (de arquivos) locais de forma a integrá-los em um único domínio (espaço). No nível 4, arquiteturas e sistemas operacionais são emulados por módulos interpretadores (denominados Emulators). Aplicações de usuários estão espalhadas dos níveis 2 a 5; a camada varia com o tipo de aplicação. Para demonstrar a viabilidade do sistema, implementou-se a estrutura fundamental do HetNOS, incluindo a DCL (um núcleo distribuído heterogêneo), a versões básicas dos módulos servidores, as bibliotecas de procedimentos, além de diversos tipos de aplicações. O sistema conta hoje com mais de 25.000 linhas de código fonte C em mais de 100 arquivos. O desempenho do subsistema de comunicação implementado pela DCL (em avaliações com diferentes configurações de hardware) superou as expectativas iniciais, mas ainda está muito aquém do necessário a aplicações distribuídas. Segundo o que indicam as primeiras experiências realizadas, o HetNOS será bastante útil na prototipação e avaliação de modelos distribuídos, assim como na programação de software distribuído homogêneo e heterogêneo. Projetos de pesquisa do CPGCC envolvendo sistemas distribuídos (p.ex., tolerância a falhas e simulações) podem utilizar o HetNOS como ferramenta para implementação e validação de seus modelos. Futuramente, aplicações distribuídas e paralelas de maior porte poderão ser programadas, como sistemas de gerencia de bases de dados distribuídas, simuladores e sistemas de controle para automação industrial. / The advent of personal computers and, later, of workstations, along with the development of efficient and low-cost communication hardware has led to the popularization of local-area networks. However, distributed software did not experiment the same development of hardware, specially due to the complexity of distributed systems. The machine, system and communication network heterogeneity, inherent to the modern computing environments, is also responsible for the lack of integration and cooperation of available nodes. The purpose of this work is, from the analysis of the main aspects related to distribution and heterogeneity, to design a heterogeneous network operating system. Such system, named HetNOS (which stands for Heterogeneous Network Operating System), allows users to quickly write and validate distributed homogeneous and heterogeneous applications. Users can concentrate their work in the distributed aspects, abstracting communication mechanisms' details, because programming of distributed applications is based on a homogeneous interface platform, easy to use and location-independent. Being a network operating system, HetNOS acts over the set of native operating systems; the environment is extended instead of substituted. There are neither centralized information nor entities, and the algorithms are always distributed, usually yielding more reliability and performance. The HetNOS topology is a logical ring, scheme adopted partly due to the generality of such configuration and partly to simplify the HetNOS distributed kernel design. The communication paradigm between modules is the message exchange, a mechanism implemented over the sockets network application programming interface. There is no shared memory at all, making the system clearer, more manutible and portable. The interrelation between modules is restricted to the message interface defined and accepted by a module. The HetNOS architecture is structured and distributed, as the system is composed of hierarchical layers divided into modules, which in their turn are realized as processes. The layer 1 is the set of native operating system kernels, over which is implemented the distributed heterogeneous HetNOS kernel, namely DCL (states for Distributed Computing Layer). The main service provided by DCL (in layer 2) is a canonical, location-independent, message exchange mechanism. Server and user processes may use multiple forms of message primitives, such as synchronous, asynchronous, blocking and non-blocking send and receive. In the layer 3 are the system servers, which extend and implement in a distributed way the functionality of native systems. The name server is a global data repository, serving other system and user processes. The authorization server implements the security scheme to control the access to the system resources. The type server allows applications to transfer structured data independently of location and architecture. Finally, the file server extends the local (file) services to integrate them into a unique domain (space). In the layer 4, architectures and operating systems are emulated by interpreter modules (named Emulators). User applications are spread over the layers 2 to 5, depending on the application type. In order to prove the system viability, the fundamental HetNOS structure has been implemented, including its distributed heterogeneous kernel, the base of server modules, the procedure libraries, and several types of applications. The system source code has over 25,000 lines of C programming distributed over a hundred files. Although the optimization is an endless process, the performance of the DCL communication subsystem (evaluated using a few different hardware configurations) overestimated initial predictions, but is weak if considered the requirements to distributed processing. Accordingly to the first experiences made, HetNOS will be of great value to evaluate and prototype distributed models, as well as to the programming of homogeneous and heterogeneous distributed software. Local research projects involving distributed systems (e.g., fault tolerance and simulations) may use HetNOS as a tool to validate and implement their models. In the future, more complex distributed and parallel applications will be programmed, such as a distributed database management system, simulators and factory automation control systems.

Este trabalho relata observações e analises sobre como os detectores de defeitos influenciam as operação de consenso. O conceito dos detectores de defeitos é essencial para as operações de consenso em sistemas distribuídos assíncronos, uma vez que esses representam uma das (micas formas de sobrepujar as limitações impostas pela chamada Impossibilidade FLP (impossibilidade de diferenciar um processo falho de um processo mais lento). Enquanto os detectores de defeitos tem seu funcionamento bem definido através de duas propriedades, completeness e accuracy, Não há nenhuma restrição quanto a forma de implementá-los. Na literatura são encontrados vários modelos de detectores de defeitos, construídos com as mais variadas estratégias, mecanismos de comunicação e de detecção. No entanto, estes modelos não costumam ser acompanhados de uma comparação com os detectores já existentes; os autores limitam-se a apresentar as inovações dos mecanismos sugeridos. De toda literatura pesquisada, apenas um trabalho procurou comparar diferentes modelos de detectores de defeitos, e através de simulações, avaliou o impacto destes detectores sobre o tempo de terminação das operações de consenso. Entretanto, aquele trabalho era bem limitado, tanto nos modelos de detectores analisados quanto nos objetivos das observações. O presente trabalho procurou estender aquele experimento, incluindo mais modelos de detectores, e transportando-os para um ambiente prático de execução. As observações realizadas não ficaram limitadas as avaliações já realizadas por aquele trabalho, de tal forma que os modelos de detectores testados foram analisados sob diversas métricas, situações e parâmetros de operação. Essas avaliações possibilitaram verificar o comportamento dos detectores frente aos padrões de falhas mais significativos, avaliar o impacto de cada detector sobre as operações de consenso e a sua interação com os elementos do ambiente de execução. Essas avaliações permitiram fazer uma comparação dos detectores, possibilitando a identificação de suas limitações, suas situações de melhor desempenho e possíveis otimizações para serem realizadas em trabalhos futuros. / This work presents our observations and analysis on the influence of the failure detectors on the consensus algorithm. Failure detectors are essential to the consensus over an asynchronous distributed system, as they represent one of the few techniques that are able to circumvent the limitation imposed by the FLP Impossibility (the impossibility to distinguish a crashed process from a slow one, in asynchronous systems). While failure detectors are well defined through two properties, completeness and accuracy, there's no rule about their implementation. Thus, in the literature there are many models of failure detectors, each one implemented using different approaches to the communication and detection strategies. However, these detectors seldom compare themselves to the existing ones; their authors usually present only the advantages and innovations of the new model. Indeed, we only found one work that tried to compare different failure detectors. Using simulation techniques, that work evaluated the impact of the failure detectors on the consensus termination time. However, that research was very limited in the number of detectors analyzed and in the evaluation goals. The present work extended that experience, including more detectors in the analysis and evaluating them in a practical environment. Also, the observations were not restricted to those from the original paper, and the detectors were analyzed with more metrics, failure patterns and operational parameters. The evaluation allowed us to identify the behavior from the detectors in face of the most significant failure patterns, their influence on the consensus operation and their interaction with the execution environment. These evaluation also enabled us to compare the detectors, identifying their limitations, their best employment situations and possible optimizations to future developments.

É ponto passivo a importância dos sistemas distribuídos no desenvolvimento da computação de alto desempenho nas próximas décadas. No entanto, ainda muito se debate sobre políticas de gerenciamento adequadas para os recursos computacionais espacialmente dispersos disponíveis em tais sistemas. Políticas de balanceamento de carga procuram resolver o problema da ociosidade das maquinas(ou, por outro lado, da super-utilização) em um sistema distribuído. Não são raras situações nas quais somente algumas maquinas da rede estão sendo efetivamente utilizadas, enquanto que varias outras se encontram subutilizadas, ou mesmo completamente ociosas. Aberta a possibilidade de executarmos remotamente uma tarefa, com o intuito de reduzirmos o tempo de resposta da mesma, ainda falta decidirmos "como" fazê-lo. Das decisões envolvidas quanto a execução remota de tarefas tratam as políticas de balanceamento de carga. Tais políticas, muito embora a aparente simplicidade quanto as decisões de controle tomadas ou ao reduzido numero de parâmetros envolvidos, não possuem um comportamento fácil de se prever. Sob determinadas condições, tais políticas podem ser tomar excessivamente instáveis, tomando sucessivas decisões equivocadas e, como consequência, degradando de forma considerável o desempenho do sistema. Em tais casos, muitas das vezes, melhor seria não tê-las. Este trabalho apresenta um ambiente desenvolvido com o objetivo de auxiliar projetistas de sistema ou analistas de desempenho a construir, simular e compreender mais claramente o impacto causado pelas decisões de balanceamento no desempenho do sistema. / There is no doubts about the importance of distributed systems in the development of high performance computing in the next decades. However, there are so much debates about appropriated management policies to spatially scattered computing resources available in this systems. Load balancing policies intend to resolve the problem of underloaded machines (or, in other hand, overloaded machines) in a distributed system. Moments in which few machines are really being used, meanwhile several others are underused, or even idle, aren't rare. Allowed the remote execution of tasks in order to decrease the response time of theirs, it remains to decide 'how' to do it. Load balancing policies deal with making decisions about remote execution. Such policies, in spite of the supposed simplicity about their control decisions and related parameters, doesn't have a predictable behavior. In some cases, such policies can become excessively unstable, making successive wrong decisions and, as consequence, degrading the system performance. In such cases, it's better no policy at all. This work presents an environment developed whose purpose is to help system designers or performance analysts to build, to simulate and to understand the impact made by balancing decisions over the system performance.

Diversas aplicações executadas em ambientes de cluster necessitam de uma área de armazenamento permanente com alta capacidade e que forneça uma visão homogênea dos dados entre todos os nós. Esta área compartilhada é comumente implementada através de um sistema de arquivos distribuído, permitindo o acesso através da abstração mais comum para gerenciamento de dados. A disparidade entre poder de processamento e desempenho de dispositivos de armazenamento atuais, no entanto, torna tais sistemas um ponto crítico ao desempenho de aplicações paralelas que lidam com grandes volumes de dados. Ambientes de cluster podem apresentar execução concorrente de aplicações em conjuntos independentes de máquinas. Desta forma, uma grande quantidade de clientes com características distintas farão acessos ao sistema de arquivos compartilhado. Em tais casos, o dimensionamento do sistema de armazenamento distribuído nem sempre poderá prover o desempenho necessário à execução das aplicações com os recursos inicialmente a ele destinados. O presente trabalho propõe uma estratégia de reconfiguração dinâmica para o sistema de arquivos dNFSp. Esta estratégia leva em consideração o comportamento temporal presente em aplicações paralelas para inserir servidores de dados exclusivos a aplicações com alta demanda de I/O. Com a utilização de servidores exclusivos, torna-se possível isolar aplicações com comportamentos que causam grande perda de desempenho no sistema como um todo. Foi desenvolvida uma ferramenta de monitoramento do desempenho junto aos servidores do dNFSp, de forma a solicitar novos servidores apenas quando a interação das fases de I/O das aplicações em execução interferirem no desempenho do sistema. Esses novos servidores são solicitados para um sistema escalonador de recursos para cluster, de forma a utilizar nós livres para o armazenamento de dados. Os resultados mostram que a estratégia proposta é capaz de detectar a saturação do sistema de armazenamento e iniciar os servidores exclusivos, levando a um ganho de desempenho para as aplicações em execução. A reconfiguração dinâmica também mostrou-se capaz de evitar baixos desempenhos causados pela interação dos períodos de inatividade de aplicações temporais e pela utilização de diversos processos de I/O em um único nó. / Several applications executed in cluster environments need a shared storage area with high capacity and a homogeneous view of the stored data to all processing nodes. This area is commonly implemented as a distributed file system, allowing the access to data through the well-known file abstraction. The great gap in performance of processors and storage devices, on the other hand, makes such system a critical point to the performance of parallel applications. A common trait of large cluster environments is the concurrent execution of applications. In this scenario, many clients with distinct behaviors will compete to access the shared storage system. The number of I/O resources originally dedicated to this shared storage may provide unsatisfactory performance to the applications in this case. This work proposes a dynamic reconfiguration strategy for the dNFSp file system. This strategy takes into consideration the temporal behavior of distributed applications to launch dedicated I/O resources to the more I/O-demanding applications. The exclusiveness of data servers allows for the isolation of access patterns that cause contention on the system, resulting in improved performance for all executing applications. We developed a tool to monitor the performance of the storage servers in order to launch new servers only when the interaction of I/O phases from running applications cause each other’s performance to drop. These resources are required to a batch scheduler system present on the cluster, allowing the use of computing nodes for temporary data storage. The results show that the proposed metrics lead to the detection of performance saturation on the file system and the start of the dedicated resources, resulting in increased I/O performance. The reconfiguration has also been able to avoid some low performance situations caused by interactions of inactivity periods from temporal applications and by utilization of several I/O processes on the same cluster node.

Em vista da maior complexidade da programação paralela e distribuída em relação à programação de ambientes centralizados, novas ferramentas vêm sendo construídas com o objetivo de auxiliar o programador desses ambientes a desempenhar sua tarefa de formas mais eficazes e produtivas. Uma das ferramentas que há algum tempo tem sido usada na programação centralizada e aos poucos está sendo empregada também na programação concorrente é a programação visual. A programação visual se vale da presença de elementos visuais na especificação dos programas como peças chaves do processo de desenvolvimento de software. No caso específico da programação concorrente, a programação visual é especialmente útil pela capacidade que os gráficos têm de representar de forma mais adequada estruturas bidimensionais. Um programa concorrente, por relacionar no espaço diversos elementos com seus próprios fluxos de execução, faz surgir duas dimensões de análise que são mais difíceis de serem observadas através de programas textuais. Atualmente existem ferramentas de programação visual paralela e distribuída, mas a ênfase é dada na programação paralela, sem muita atenção a aplicações de sistemas abertos ou cliente-servidor. Além disso, tais ferramentas sofrem da falta de apoio à engenharia do software. Considerando essas deficiências, este trabalho apresenta uma ferramenta de programação visual para o desenvolvimento de aplicações compostas por objetos distribuídos que ofereça também a possibilidade de aplicar os principais conceitos da engenharia de software, como reutilização e orientação a objeto. Nesta ferramenta, o programador especifica de maneira visual a estrutura do seu programa, insere o código textual para a lógica da aplicação e o ambiente se encarrega do tratamento da distribuição e da comunicação de mais baixo nível. A aplicação é representada como um grafo dirigido, onde os nodos representam os objetos distribuídos e os arcos indicam os relacionamentos existentes entre esses objetos. A especificação dos programas é modular, baseando-se na reunião de componentes reutilizáveis, o que torna o sistema altamente configurável e extensível. Tanto a implementação da ferramenta quanto o código das aplicações geradas usam a linguagem de programação Java. A linguagem de programação visual projetada não especifica detalhes a respeito de como irá funcionar a comunicação e distribuição dos objetos. Portanto, foram implementados componentes para comunicação e outros recursos de programação distribuída, como locks e dados globais para serem usados nas aplicações. Para validar os principais objetivos da ferramenta, foram implementados alguns exemplos de aplicações distribuídas, como um pequeno sistema de bate-papo.