em Kerrighed
Considerações iniciais do capítulo
Apresentaremos nesse capítulo os principais sistemas de cluster de alto desempenho em Linux na nossa visão, entrando num maior detalhamento quando abordarmos o sistema de cluster Kerrighed que será foco do nosso laboratório.
Usaremos como comparação 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 multinúcleo de baixo custo está fazendo que rapidamente a clusterização com SSI (Single System Image) diminua sua importância na computação. A direção da computação é clara e as desenvolvedoras chaves estão migrando para novas abordagens de virtualização e outros projetos.”
Apesar de respeitarmos a opinião do criador do projeto, ainda achamos que plataformas como o OpenMosix ainda são viáveis técnica 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 aplicações nesses ambientes.
O projeto do OpenMosix, pelo menos, no que tange ao conceito de migração de processos tem sido continuado através do projeto “LinuxPMI”, porém sem ter um envolvimento efetivo da comunidade acadêmica e tecnológica.
Classificação de Michael J. Flynn 15 (FLYNN, 1972) das arquiteturas de Computadores
Michael Flynn concebeu uma classificação de arquiteturas de computadores através de modelos, baseada no número de fluxos de dados e de instruções existentes em cada instante que em sua concepção são quatro:
15
Michael J. Flynn é um cientista da computação dos Estados Unidos, professor emérito 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. Propôs a taxonomia de Flynn em 1966, uma forma de classificação de arquiteturas de computador de acordo com instrução e fluxo de dado.
133
Arquitetura SISD (Single Instruction, Single Data): é o modelo mais simples, onde o computador processa sequencialmente, executando uma instrução 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 várias instruções ao mesmo tempo sobre um único dado. Não existe um computador real nesse modelo, pelo menos, atualmente. O próprio 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 instrução é executada paralelamente utilizando vários dados. Essa tecnologia é utilizada em alguns processadores, conhecida como MMX (MultiMedia eXtension) e também nos computadores vetoriais, computadores usados para efetuar operações aritméticas sobre vetores e matrizes de ponto flutuante.
Arquitetura MIMD (Multiple Instruction, Multiple Data): é o modelo de execução paralela onde cada processador trabalha de maneira independente, ocorrendo múltiplos fluxos de instruções e múltiplos dados. Esse é o modelo utilizado nos clusters de computadores, utilizando a variação arquitetura MIMD com memória distribuída, que nesse caso seria vários computadores com seu próprio processador e memória executando múltiplas instruções com múltiplos dados conectados através de uma rede local.
Tipos de clusters
Podemos dividi-los em dois grupos, cluster de Alta Disponibilidade e cluster de Alta Performance de computação.
Cluster de Alta Disponibilidade:
Como o próprio nome já indica, o objetivo é manter o sistema o maior tempo possível na operação sem paradas não programadas, replicando os serviços e servidores. Quando algum serviço ou equipamento paralisar, os outros passam a responder automaticamente. Enquanto um servidor de boa qualidade, inclusive com redundância de discos rígidos, apresenta uma disponibilidade de 99,5%, um sistema de cluster de Alta disponibilidade apresenta 99,9%.
134
Esses quatro décimos podem parecer não muito significativos à primeira vista, mas para sistemas críticos são inestimáveis. Alguns sistemas de alta disponibilidade em Linux com o código fonte aberto são: LVS (Linux Virtual Server), Eddiware e o TurboLinux Cluster.
Cluster de Alta Performance de Computação
Esse modelo tem como foco desenvolver um sistema que tenha a mesmo poder de computação de um supercomputador, através do agrupamento de computadores numa rede de alta velocidade e softwares que agregam capacidade de memória e processamento desses computadores como se fosse apenas uma máquina, podendo assim executar aplicações que só seriam suportadas por supercomputadores ou computadores de grande porte.
Nosso trabalho trata de Clusters de Alta Performance de Computação, sendo assim apresentaremos com mais detalhes alguns modelos que se enquadra nessa classe de agrupamento de computadores.
Cluster Beowulf:
O nome desse sistema vem de um dos mais antigos épicos da língua Inglesa, onde o protagonista é um cavaleiro inglês, de grande força e coragem, em sua luta contra o monstro de Grendel.
Esse modelo de cluster foi concebido pela NASA com intuito de alcançar e avançar na capacidade de processamento massivamente paralelo (Massively Parallel Processing) MPP e aplicá-los para resolução de problemas computacionais, especialmente na aerociência 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 são setenta milhões de operações em ponto flutuantes por segundo. Ponto flutuante é uma forma de representação mais apropriada para computadores de números com muitas casas decimais.
135
Segundo Marcos Pitanga16 (PITANGA, 2002), para um cluster de PC's ser considerado
um Beowulf, precisa atender às seguintes características: Nenhum componente feito por encomenda;
Independência de fornecedores de hardware e software; Periféricos escaláveis;
Software livre de código aberto;
Uso de ferramentas de computação distribuída disponíveis livremente com alterações mínimas;
Retorno à comunidade do projeto e melhorias;
O Beowulf tem como vantagem ser escalável, transparente ao hardware e sem nenhum custo em termos de software.
Os elementos essenciais de um cluster Beowulf são: Os nós;
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 nós trabalhem como um recurso integrado, fornecendo ao usuário uma interface como se estivesse trabalhando num computador individual.
As ferramentas de comunicação que usam como recurso o PVM (Parallel Virtual Machine), que permite a execução de programas paralelos em ambientes heterogêneos assim como o MPI (Message Passing Interface) que permitem a programação, através de troca de mensagens. Essas ferramentas também incluem API’s (Application Programing Interface).
16 Marcos Pitanga possui mais de 23 anos de experiência em TI no Brasil e no exterior, com formação em
Sistemas de Informações, com pós-graduação em Redes de Computadores e Segurança de Redes. Docente em algumas universidades nas cadeiras de Redes de Computadores, Sistemas Operacionais e Sistemas Distribuídos e Segurança de Redes.
136
Sistema de arquivos paralelo que são bibliotecas de interfaces que permitem visualizar os discos rígidos dos nós como se fosse um único disco virtual.
Segue um esquema lógico simplificado de um cluster Beowulf:
Figura 16
O nó controlador do cluster funciona como uma interface de saída para o acesso externo à outra rede, seja ela uma rede local ou a própria Internet. Os usuários se conectam nessa máquina para acessar os recursos do cluster.
Os nós escravos são os computadores onde as aplicações serão executadas de modo paralelo, compartilhando assim os recursos de memória, processador e disco rígido. Um problema no modelo Beowulf é que se o nó controlador se danificar, perde-se toda a base de usuários, assim como o acesso aos nós escravos. Nesse caso recomenda- se uma redundância de disco nesse computador assim como uma política consistente de backup.
137
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 instalação e o uso de clusters, ampliando o seu uso. Ao longo dos anos muitas empresas têm suportado o Open Cluster Group, incluindo Dell, IBM, Intel, NCSA and ORNL, dentre outras.
Como o OSCAR é desenvolvido como uma solução completa de clusterização há muitas áreas funcionais que precisam ser cobertas pelos componentes do mesmo. Essas áreas incluem instalação, ambiente de processamento paralelo, gerenciamento de carga de trabalho, segurança e administração e manutenção em geral. Para satisfazer o requerimento de cada área, os componentes do software incluídos no OSCAR foram selecionados através da investigação das práticas de muitas implementações independentes de computação em cluster. O resultado foi uma coleção de softwares que representam, segundo a proposta dos desenvolvedores do OSCAR, “as melhores práticas” para criar-se um exitoso ambiente de cluster.
O OSCAR trabalha com o conceito de um servidor ou head e nós 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 instalação ativa um servidor DHCP (Dynamic Host Configuration Protocol) na interface private para fornecer endereçamento IP automático para os nós.
138
O pacote de instalação do OSCAR é dividido em três partes principais: o core cuja instalação é mandatória, pacotes que são distribuídos como parte do OSCAR, mas a instalação é 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 administração em linha de comando do cluster, para comandos e controle.
Environmental Switcher: baseado em módulo, sendo um script em linguagem Perl que permite o usuário fazer mudanças para futuros ambientes shells.
Oda: uma aplicação 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 difícil na criação com sucesso de um ambiente em cluster seria a instalação inicial do software responsável por fazer máquinas independentes trabalharem juntas com um único recurso computacional. 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 razão de o LUI ter sido escolhido como mecanismo de instalação do OSCAR foi que ele não requer que os nós clientes já tenham o Linux instalado, nem requer uma imagem em disco para o nó cliente como outras técnicas de instalação requerem. O LUI apresenta uma série de qualidades, como um banco de dados que contém todas as informações para um nó instalar-se e configurar-se no cluster, a utilização de RPM (Red Hat Package Manager) e sua característica heterogênea, podendo ser instalado em hardwares e softwares diferentes.
Tratando do processamento paralelo, o OSCAR suporta o conceito de passagem de mensagem e provê as implementações mais comuns a MPI (Message Passing Interface) e a PVM (Parallel Virtual Machine). Em meio às várias versões de MPI disponíveis, os desenvolvedores do OSCAR optaram pela MPICH (MPICHamaleon).
139
Projeto Rocks
O projeto Rocks teve início em novembro de 2000, pelo SDSC (San Diego Supercomputer Center) que disponibilizou uma primeira versão conhecida como NPACI Rocks Cluster, que era um conjunto de ferramentas baseadas em Red Hat visando à construção e administração de maneira rápida e prática de clusters para a comunidade científica.
Apesar de havermos apresentado brevemente o conceito de grid na introdução desse trabalho, como o Rocks tem uma aplicação também em sistemas em grid, vale elucidar um pouco mais o tema, apesar de o mesmo não ser o foco desse trabalho. A computação em grid é uma combinação de recursos computacionais de domínios administrativos múltiplos aplicados para uma tarefa comum, usualmente para solução de problemas de natureza científica, técnica ou corporativa que requer um grande número ciclos de processamento de computador ou necessite processar uma grande quantidade de dados.
Uma das principais estratégias da computação em grid é utilizar softwares para dividir e aportar partes de programas em muitos computadores e formar uma rede de processamento paralelo e distribuído. O tamanho de um grid pode variar de muito pequeno, confinado a uma rede de computadores dentro de uma corporação, por exemplo, ou muito grande, através de uma colaboração pública entre muitas companhias e redes, usualmente utilizando a Internet como meio de comunicação. Dizemos que os sistemas em grid seria um cluster com computadores “fracamente acoplados” em termos de conexão de rede, pois não são recursos dedicados completamente à formação desse computador virtual como no caso dos clusters convencionais em que os componentes são considerados “fortemente acoplados”. O que também distingue a computação em grid dos clusters convencionais seria a heterogeneidade de seus componentes assim como a dispersão geográfica dos mesmos.
Retornando aos conceitos do Rocks, um cluster com essa tecnologia tem a mesma arquitetura básica do OSCAR. O nó head também conhecido como front end é um servidor com duas interfaces de rede como ilustrado na Figura 17.
140
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 comunicação e passagem de mensagem;
Aplicações para ambiente em cluster (Códigos Paralelos, Grid, etc);
O Rocks é cluster completamente baseado em distribuição Linux Red Hat com pacotes adicionais e configuração programada para automatizar a implementação de um cluster Linux de alto desempenho. Escolha da distribuição Linux Red Hat, segundo os desenvolvedores, teve como motivo principal a existência de dois mecanismos chaves, a saber: o software de manipulação de pacotes RPM e sua ferramenta baseada em script para instalação, especialmente dos nós da solução (kickstart). Segundo os desenvolvedores, apesar do Rocks ter um foco num sistema rápido e flexível de configuração e reconfiguração, o comportamento estável do Rocks faz dele uma solução de cluster de mercado como Beowulf e o próprio OSCAR.
Uma das premissas do desenvolvimento do Rocks foi criar um software de instalação, gerenciamento e monitoramento facilitado mesmo para clusters de grande porte, tornando acessíveis essas atividades mesmo para não especialistas. O mesmo possui um kit de ferramentas baseado na distribuição Red Hat, utilizando recursos de muitos projetos populares de grids e clusters. Adicionalmente, o Rocks permite que usuários finais adicionem seus próprios softwares através de um mecanismo chamado “Rolls”. Rolls que é uma coleção de pacotes e detalhes de configuração que podem ser modularmente acrescidos na base de distribuição do Rocks.
141
Cluster OpenMosix
O projeto Mosix (Multicomputer Operating System UnIX), é um sistema operacional distribuído desenvolvido na Universidade Hebrew em Jerusalém, Israel. Sendo utilizado nos anos 80 pela Força Aérea Americana, chegando numa versão final desse projeto em 1997 utilizando plataforma Intel e sistema operacional GNU/Linux. O código do mesmo está disponível em www.mosix.org, gratuitamente apenas para instituições acadêmicas.
O OpenMosix é um extensão do projeto Mosix, baseado em licença de software livre GPLv2 (hoje já temos a GPLv3), iniciando em 10 de fevereiro de 2002, sob coordenação do Ph.D Moshe Bar, visando manter essa solução de cluster como código aberto, devido divergências com a Universidade de Hebrew quanto a questão de direitos autorais.
Durante a sua vigência o OpenMosix teve o apoio técnico e financeiro de muitas instituições privadas e públicas.
Tendo como principal desenvolvedor o Dr. Moshe Bar, teve também ampla colaboração da comunidade acadêmica, destacando como membros do projeto, Dr. Maurizio Davini17, Dr. David Santo Orcero18, dentre outros.
O OpenMosix é uma extensão 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 múltiplas estações monoprocessadas e mesmo multiprocessadas simetricamente executem o mesmo kernel, podendo trabalhar numa significativa cooperação. Isso é alcançado através da migração de processos de um nó para outro de modo preemptivo e transparente, para balanceamento de carga e prevenção de trashing em processos de paginação de memória. O objetivo seria o melhor desempenho de modo geral num sistema de cluster e a criação de um ambiente multiusuário e time-sharing para a execução de aplicações sequenciais e paralelas.
17
Consultor da equipe Ferrari de corridas e chefe do Departamento de Física da Universidade de Pisa.
18
142
Assim o OpenMosix é um sistema de cluster onde todos os recursos estão disponíveis em todos os nós que o compõe, podendo ser constituído de computadores de baixa capacidade de processamento e em redes convencionais, mas também podendo ser utilizado em ambientes com servidores de alta performance e em redes de alta velocidade e baixa latência.
A granularidade no OpenMosix é determinada pela migração dos processos. Programas individuais podem criar processo ou processos que podem ser gerados através de múltiplos forks de um único programa. Entretanto, se temos uma tarefa intensiva em termos computacionais que é executada num simples processo, utilizando-se múltiplas threads, desde que não exista no próprio computador outro processador para compartilhar essa carga, esse processo seria elegível para ser migrado para outro nó do cluster.
Naturalmente nem todos os processos são migrados num cluster OpenMosix. Por exemplo, se um processo dura poucos segundos, ele não terá tempo nem necessidade de ser migrado. Da mesma forma, múltiplos processos utilizando memória compartilhada, tais como servidores WEB, não são adequados para serem migrados, pois o OpenMosix não tem um sistema memória distribuída eficiente. Processos que atuam na manipulação direta de dispositivos de E/S também não migrados, porque o OpenMosix não possui um mecanismo de migração baseado em sockets.
Similarmente os processos que utilizam escalonamento em tempo real também não seriam a princípio migrados. Existe uma proposta de pesquisadores da Syracuse University (OH, 2005), que utiliza uma combinação 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 solução elegante, especialmente no que diz respeito a não necessitar de um nó controlador, como no cluster Beowulf, que sempre será um ponto único de falha e de gargalo, o OpenMosix tem suas limitações e desvantagens. Assim ao utilizar essa plataforma há necessidade de escolher as aplicações compatíveis com a mesma. Seguem algumas diretrizes para um uso eficiente do OpenMosix.
143
Aplicações que têm um bom desempenho com o OpenMosix:
Processos CPU-bound. Processos com longo tempo de execução e baixa utilização dos recursos de rede, por exemplo, aplicações científicas, matemáticas, de engenharia, etc.
Compilações extensas.
Processos com moderada comunicação interprocessos.
Processos de uso intenso de E/S em disco, utilizando o sistema de arquivos distribuídos do OpenMosix.
Bancos de dados que não utilizam memória compartilhada. Processos que podem ser migrados manualmente.
Tecnologia do OpenMosix
O OpenMosix é constituído de duas partes: o mecanismo PPM (Preempetive Process Migration) e um grupo de algoritmos para compartilhamento adaptativo de recursos. Ambas as partes são implementadas em nível de kernel, utilizando módulos carregáveis (via RPM ou compilação direta do kernel), de tal forma que a interface do Sistema Operacional permanece inalterada, sendo completamente transparente em nível de aplicação.
O PPM pode migrar qualquer processo, a qualquer momento, para qualquer nó disponível. Usualmente as migrações são baseadas em informações providas por algum dos algoritmos de compartilhamento de recursos, mas os usuários podem sobrepor qualquer sistema automático de decisão 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 usuário 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 próprio UHN e todos os processos de uma sessão de usuário compartilham o ambiente de execução do UHN. Processos que migram para outro nó usam os recursos locais (do nó remoto) sempre que possível, mas interagem com o ambiente do usuário através do UHN.
144
O PPM é a principal ferramenta para os algoritmos de gerenciamento de recursos. Enquanto o requerimento de recursos, tais como utilização de CPU e memória principal estiver abaixo de certos limites, os processos do usuário estarão confinados ao UHN. Quando os requerimentos de recursos excederem os níveis estabelecidos, então algum processo pode ser migrado para algum outro nó.
O principal objetivo é maximizar o desempenho através de uma utilização eficiente dos recursos disponíveis na rede.
O OpenMosix não tem um controle central no modelo mestre/escravo. Cada nó opera como um sistema autônomo, tomando as decisões de controle baseado nos