Desde sua primeira aparição em 1998 na lista dos 500 computadores mais rápidos do mundo, clusters Linux passaram de um experimento obscuro de ciências para a posição de força dominante de hoje em tecnologia de supercomputação. De fato, o número de clusters Linux na lista dos 500 Mais Importantes cresceu de 1 sistema em 1998 (1 cluster, 1 S.O. Linux) para quatro-quintos da lista em 2008 (400 clusters, 458 S.O.'s Linux).

Gerenciar clusters Linux requer um conjunto exclusivo de habilidades, que não são encontradas geralmente entre os administradores de TI de sistema único ou de sistemas pequenos de interligação de redes -- requer conhecimento profundo de interligação de redes, de sistemas operacionais e de quase todos os subsistemas na arquitetura.

Mas isso não é tudo: é necessária uma postura diferente. É necessária preguiça mais do que tudo. É preciso que o administrador faça o que o Scrooge McDuck disse aos seus sobrinhos em Duckburg: "Trabalhe com mais inteligência, não mais arduamente."

Nesse artigo serão discutidos alguns dos melhores segredos dos administradores de clusters Linux mais preguiçosos. Embora dificilmente elas possam ser chamadas de segredos, por alguma razão as pessoas não entendem ou subestimam o poder dessas idéias. Para esclarecer essa questão, serão apresentados os segredos aqui com uma explicação de sua importância.

Os segredos são

1. Não reinvente a roda.
2. Utilize software livre.
3. Automatize tudo.
4. Projete para escala - planeje ser preguiçoso desde o início.
5. Projete para gerenciamento de hardware.
6. Utilize bom software de gerenciamento de clusters - não cave poços com colheres de chá.
7. Utilize soluções de monitoramento de software livre.
8. Controle seus usuários com um sistema de enfileiramento.
9. Verifique se obtém aquilo que está pagando - avalie o desempenho disso!
10. Gerencie a comunicação do cluster.
11. Procure maneiras para tornar-se mais preguiçoso.

1. Não Reinvente a Roda

O administrador preguiçoso de clusters Linux não está no negócio de criar a roda; ele concentra-se em se aproveitar do trabalho de outros. Não há sentido em perder tempo construindo um aplicativo quando uma solução gratuita suportada já existe.

Uma das coisas mais raras no mundo é uma ideia original ou um problema original -- especialmente no mundo de clusters Linux. Raramente será encontrado algo que não tenha sido enfrentado e resolvido já em 2004. Isso não deve fazê-lo sentir-se não importante ou não original; antes, é preciso sentir-se confiante de que realmente não há nenhum problema que não possa ser solucionado (falando tecnicamente, não política ou socialmente). Portanto, aceite o fato de que a maioria dos problemas e suas soluções foram reconhecidas, diagnosticadas e solucionadas.

Para perder menos tempo, o administrador eficiente passa mais tempo:

• Pesquisando soluções que existem e adaptando-as para suas próprias necessidades. Isaac Newton citou Bernard de Chartres quando observou que em seu trabalho ele se manteve "sobre os ombros de gigantes." imagine o que teria sido perdido se ele não tentasse primeiro entender os Euclid's Elements e, em seguida, baseou-se em outros.
• Contribuindo ou customizando projetos de software livre em vez de reinventar algo que já foi feito - sabendo muito bem que se escrever algo, isso irá provavelmente desaparecer quando ele sair para um novo trabalho porque ninguém mais entenderá isso.

Nós não pretendemos reprimir a sua criatividade -- muito pelo contrário. Utilizar o trabalho já feito por outros permite que seja construída a próxima camada que fará seu ambiente bem mais superior e eficiente do que aqueles em outras organizações.

2. Utilize Software Livre

Os administradores de clusters Linux mais bem-sucedidos com quem trabalhamos possuem um vasto conhecimento de projetos de software livre atuais. Eles são os contribuidores frequentes para listas de endereçamento e seus nomes são aqueles associados com projetos atuais quando você procura na Internet. Eles geralmente procuram em http://sourceforge.net e em http://freshmeat.net por novos projetos que lhes interessam.

As ferramentas de software livre possuem propriedades que lhes permitem viver mais tempo do que a pessoa que as defende, especialmente as populares. Existe uma razão muito boa para ferramentas como Ganglia, Nagios e TORQUE ainda estar em uso apesar de estar disponíveis por um longo tempo. Elas são boas -- economizam administração em custos e em esquemas de licenças de software.

Um outro aspecto dos administradores mais preguiçosos de clusters é que eles são totalmente entusiasmados a respeito de software livre e o utilizam em seus próprios interesses pessoais. Isso pode ser seus próprios servidores da Web em casa ou aplicativos que eles executam em seu próprio notebook Linux. Do Pidgin até o Firefox, você verá que os administradores Linux mais preguiçosos executam Linux em algum outro aspecto de suas vidas distinto dos clusters que gerenciam no trabalho.

3. Automatize Tudo

Utilizar scripts na linha de comando e outras gravações rápidas são uma grande parte da caixa de ferramentas do administrador Linux. A programação de script (desde que não reinvente nada) fornece dois resultados úteis:

• O primeiro e o mais óbvio é que ela economiza digitação e fornece um padrão que pode ser repetido.
• O segundo é que ela é auto-documentável e pode ser consultada novamente mais tarde.

Vemos muito frequentemente administradores qualificados com diretórios para scripts que gravaram em suas máquinas. Esses scripts executam tudo desde a verificação de versões de firmware nos nós até o mapeamento de GUIDs em um cluster InfiniBand.

Um exemplo no qual a programação de script é bem apropriada é aquele da geração de uma imagem do sistema operacional, seja ela sem preservação de estado ou com preservação de estado. Se um administrador possui uma "imagem de ouro" que precisa ser propagada a cada nó de cálculo no sistema, ele deve saber o que está nele. Possuir um script que cria essa imagem é a melhor documentação disponível porque explica exatamente o que é feito e pode ser repetido. Sem scripts para construir imagens, ocorre a distensão de imagem e isso consome mais espaço e diminui a velocidade do sistema.

Muitas vezes nos deparamos com organizações com uma imagem de ouro que eles têm cultivado desde 2000. A razão maior: Eles não sabem como reconstrui-la. A segunda e provavelmente a melhor razão: Porque seu aplicativo foi testado e "certificado" nessa imagem. Certificado é um dos termos encontrados que é tão nebulosa como a definição de computação em nuvem (que por sinal não é um termo patenteado nem com marca registrada).

O segredo do por que você deve querer automatizar coisas é este: É preciso mais poder cerebral para evitar trabalhar do que para realmente trabalhar. O administrador preguiçoso de clusters Linux não aceita trabalho que transforme seu cérebro em geléia. Se tiver que efetuar ssh em cada máquina no cluster e executar um comando, não está sendo preguiçoso o suficiente. Todos os comandos para nós devem ser feitos ao mesmo tempo utilizando comandos ou procedimentos paralelos. Se o seu fornecedor de hardware não possui ferramentas Linux para automatizar atualizações BIOS ou flashing de subsistema, é necessário incluir isso como fator em seu custo de aquisição.

As dicas 8 e 10 em nosso último artigo em "Lazy Linux: 10 Truques Essenciais para Administradores" documentaram várias técnicas de programação de script da linha de comando que utilizamos frequentemente. Existem muitas outras maneiras de fazer isso, algumas das quais podem ser mais eficientes, mas essas dicas apenas dão uma ideia do que pode ser feito.

4. Projete para Escala e Planeje Ser Preguiçoso Desde o Início

Segredo Número 3 (automatizar, automatizar, automatizar) é um grande objetivo, mas é apenas uma etapa no caminho para preguiça completa. Para o mais preguiçoso dos administradores, a preguiça completa só pode ser obtida com gerenciamento de scale-out autônomo. A primeira etapa nessa busca é um sistema imune a operações que não escalam.

Clusters scale-out muito grandes são infestados com gargalos. Isso é, a maioria dos administradores de scale-out utiliza TFTP para inicialização da rede ou instala grandes conjuntos de máquinas. Como qualquer administrador experiente orientado para scale-out pode lhe informar, o TFTP não é confiável e não escala. Sem o controle de hardware remoto adequado, uma falha massiva de TFTP poderia requerer que o administrador preguiçoso realmente saísse de sua cadeira (cama) e andasse até o datacenter (não para casa) para reconfigurar cada uma das máquinas (trabalho inútil)! Mesmo com o controle de hardware remoto adequado, o administrador preguiçoso terá que parar de jogar UaU o tempo suficiente para emitir comandos periodicamente (trabalho inútil, de novo) para reconfigurar os nós em uma escala menor a fim de ter o sistema operacional.

Com um pouco de gerenciamento de planejamento direto, gargalos (como o seguinte) podem ser evitados.

Gargalo nº 1: Serviços de Provisão

DHCP, TFTP, HTTP, NFS e DNS são os serviços mais comuns utilizados para clusters de provisão. Cada um deles tem um limite -- TFTP é o pior quando se trata de ajuste de escala. Felizmente, todos eles podem ser facilmente replicados para ajudar com a escala.

Dica: Isolar DHCP e TFTP em um NIC diferente aumentará dramaticamente a escalabilidade. Por exemplo, foi medido o ajuste de escala do TFTP em 40:1 se houver compartilhamento com o NIC com outros serviços de provisão; 80:1 se não houver compartilhamento de serviços ou inicialização sem preservação de estado.

Gargalo nº 2: A Rede

A rede é frequentemente a parte mais desconsiderada de qualquer design. Nós estamos nos referindo à rede GigE utilizada para gerenciamento, redes não especializadas de alto desempenho utilizadas para tráfego de aplicativos. Embora em muitos casos haja apenas uma rede que deve ser compartilhada para dados e gerenciamento, isso pode compor qualquer problema de ajuste de escala.

Tenha cuidado ao projetar redes hierárquicas que não seja subscrita em excesso. Se uma proporção 80:1 de nó para nó de serviço for necessária, certifique-se de que essa proporção seja mantida ou excedida ao longo da malha.

Gargalo nº 3: Não Morda Mais do Que Pode Mastigar

Quando nós projetamos grandes clusters scale-out, adotamos uma abordagem cluster-de-clusters. Cada subcluster ou scalable-unit (SU) é um bloco de construção que escala dentro dele mesmo para todas as operações de cluster, (por exemplo, instalar, inicialização da rede, flashing do BIOS, monitoramento, etc.). Cada SU possui um ou mais (dependendo do tamanho da SU) nós de serviço para fornecer os serviços necessários para controlar, monitorar e provisionar todos os nós na SU. Para auxílio adicional em gerenciamento escalável, cada SU possui seu próprio domínio de transmissão (comunicações SU-para-SU e SU-para-o Mundo são roteadas -- verifique se há gargalos).

O nó de gerenciamento central e nós de serviço possuem uma rede física ou virtual privada, de forma que a agregação de informações dos nós de serviço e dos dados enviados aos nós de serviço não competem com outro tráfego de clusters. Nos referimos a essa rede, ao nó de gerenciamento e aos nós de serviço como a hierarchal management cloud ou HMC. Sua configuração e operação está exclusivamente no domínio dos administradores.

Essa abordagem cluster-de-clusters permitirá ao administrador preguiçoso projetar sistemas que podem escalar além de qualquer orçamento e permitirá ao mesmo administrador o controle central sem medo de que operações massivas falharão.

5. Projete para o Gerenciamento de Hardware

Estamos surpresos com o número de administradores que não pensam em termos de "luzes apagadas" ao projetar seus clusters. Administradores eficientes operam clusters de luzes apagadas, significando que os clusters ficam em salas escuras longe de humanos e, idealmente, passariam semanas ou meses antes que realmente precisassem ver as máquinas físicas nas quais trabalham diariamente. Em alguns casos, eles nunca verão as máquinas porque as estão gerenciando a partir do outro lado do mundo. É claro, o mais preguiçoso nem sabe onde o datacenter está -- ele é apenas um conjunto de nomes de host ou endereços IP.

Centros de dados são barulhentos e às vezes frios (e quem sabe, talvez perigosos); o administrador preguiçoso os evita a todo custo. Quem sabe os risco de saúde até agora não descobertos de estar em salas com muitas máquinas. Conforme os custos de energia/resfriamento/provimento de pessoal sobem, as tendências são em direção da mudança de centros de dados para locais que são menos dispendiosos para operar. Com isso em mente, ter o controle remoto absoluto deve ser considerado como essencial ao gerenciamento de um cluster Linux agora e para o futuro imediato.

Fornecedores de hardware cederam grandemente aos desejos dos clientes por padrões que gerenciem sistemas remotamente. O IPMI 2.0 tornou-se o padrão atual para a maioria de clusters Linux gerenciados. O IPMI oferece uma maneira de reinicializar uma máquina, assim como ter o console remoto visível para ver o boot da máquina a partir do BIOS. Em um site do cliente, pudemos solucionar problemas de uma máquina que estava a 97 quilômetros de distância, no conforto do escritório do cliente. (O cliente era um daqueles administradores Linux preguiçosos cujo escritório era iluminado apenas pelas placas de neon em sua parede. Seu apartamento de solteiro transformado em escritório também era equipado com dois refrigeradores carregados com bebidas energéticas e com petiscos cobertos com açúcar. Desnecessário dizer, não queríamos sair do escritório.)

O IPMI é eficaz -- seria possível alterar as configurações do BIOS, reinicializar os nós, observá-los inicializar e ver o dump de tela sem nunca ver a máquina - ele deveria ser configurado em todos os clusters. é necessário sempre demandar pelo menos:

• Energia remota nas máquinas e
• Console remoto ou melhor visualização das máquinas para ver problemas de inicialização que possam surgir.

Com o IPMI, vemos pouca necessidade no espaço de cluster Linux para outras caixas que meramente fornecem uma esplêndida interface para executar IPMI em vez de talvez um nó de gerenciamento. Em vez disso, recomendamos ferramentas de software livre padrão como ipmitool que chegam empacotadas já com a maioria das distribuições Linux. Descobrimos que nossos administradores mais preguiçosos de cluster Linux viverão e morrerão pela linha de comando.

O que ainda está aberto à discussão é a confiabilidade do IPMI em console remoto. Reconhecemos que há vezes em que um servidor de terminal out-of-band real pode ser de valor. Servidores de terminal como o Cyclades ACS48 continuam a ser um investmento razoável e fornecem acesso out-of-band e confiabilidade que o IPMI não entrega totalmente.

Além disso, o IPMI 1.5 não era o IOHO mais confiável (e ele era um problema de todo o segmento de mercado). O IPMI 2.0 faz um melhor trabalho e muitos fornecedores incluem páginas da Web sofisticadas em torno dele para fazê-lo parecer que é out-of-band o suficiente. Existem argumentos para incluir e não incluir servidores de terminal e utilizar apenas o IPMI nativo na máquina. A maioria das linhas de pensamento de nossos clientes são como o seguinte: Cada administrador Linux preguiçoso sabe que passa uma grande parte do tempo resolvendo problemas de 5 por cento dos nós quando 95 por cento deles estão indo muito bem. Em um caso como esse, talvez seja melhor simplesmente comprar mais 5 por cento de nós ao invés de infraestrutura e ter peças extras. Isso então significa que o orçamento é gasto mais em energia de cálculo do que em infraestrutura.

O argumento que rebate esse é que se um servidor de terminal pode economizar uma viagem de avião pelo país para solucionar problemas de um nó, então, a despesa vale a pena. Nós deixamos o administrador Linux preguiçoso fazer a chamada -- afinal, é ele quem tem que subir no avião. Nós vimos opiniões fortes dos dois lados.

6. Bom Software de Gerenciamento de Cluster Evita que Você Cave Poços Com Colheres de Chá

As ferramentas de cluster percorreram um longo caminho desde a primeira vez em que iniciamos a instalação de clusters Linux em 1999. Naquela época, não haviam muitas ferramentas de gerenciamento de clusters disponíveis e dessa forma, a maioria dos administradores criou conjuntos internos de ferramentas que implementavam, monitoravam e gerenciavam seus clusters.

Os administradores mais preguiçosos adotaram ferramentas de software livre ou disponibilizaram para a comunidade as ferramentas que desenvolveram em 1999. Raramente alguém possui um ambiente tão exclusivo que as ferramentas de software livre não possam preencher essa lacuna. Muitas vezes, aqueles que patrocinam suas próprias ferramentas geralmente estão sozinhos e quando deixam uma organização, suas ferramentas desaparecem. No entanto, nós reconhecemos que existem muitos sites nos quais ferramentas customizadas funcionam muito bem.

Se não estiver satisfeito com as suas ferramentas internas ou estiver procurando algo melhor, considere examinar várias ferramentas de software livre. Entre os mais predominantes para gerenciar clusters estão OSCAR (Criador de Imagens do Sistema), ROCKS, Perceus e nosso favorito pessoal xCAT 2. Todos eles são softwares livres.

Talvez a solução de implementação/controle de cluster de software livre mais conhecida hoje seja o ROCKS. O ROCKS foi criado e mantido pela UCSD e eles fizeram um bom trabalho em criar clusters simples e fáceis. Nossa única queixa é sua falta de flexibilidade, principalmente no nível de S.O. O ROCKS é baseado em distribuições Red Hat, o que é bom para muitas pessoas, mas não para aquelas que utilizam SUSE ou desejam utilizar imagens que criaram com base em distribuições RH 6.2. Além disso, o ROCKS não é uma solução de clonagem que encontramos muitas organizações de TI utilizando.

O Perceus é uma outra dessa solução que difere do ROCKS pois ele é uma instalação sem preservação de estado. Para os propósitos desse artigo, nós definimos a computação sem preservação de estado como executando o seu sistema operacional na memória ao invés de mantê-la em disco. Um disco não é necessário, mas pode ser utilizado para rascunho local ou para troca.

O que gostamos a respeito do xCAT além de nosso interesse investido (divulgação integral; contribuímos com código e desenvolvemos ativamente o xCAT) é que ele tem mais flexibilidade, escala mais e tem mais energia que qualquer uma das outras ferramentas. (E ele tem os contribuidores mais bonitos e inteligentes.) O supercomputador mais rápido na terra, o sistema LANL RoadRunner (o Cell/B.E.™/Opteron™ híbrido que é o primeiro sistema de um petaflops e o primeiro cluster Linux de um petaflops) é gerenciado pelo xCAT.

O xCAT permite a criação de imagem, introdução rápida, autoyast, iscsi e sem preservação de estado para quase todas as distribuições Linux disponíveis. Além disso, ele possui ferramentas de linha de comando que resumem comandos do IPMI desde a energia remota até a configuração do console e as utiliza na mesma estrutura. O xCAT foi desenvolvido ativamente desde 31 de outubro de 1999 e se tornou software livre pela IBM em 2007.

Mas, para sermos justo, mencionaremos as desvantagens do xCAT também:

• Ele pode ser difícil para configurar; com tanta flexibilidade há muitos parâmetros configuráveis. Nós configuramos um wiki para tornar isso mais fácil e há bastante suporte por meio das listas de endereçamento e de canais do IRC.
• O xCAT 2 é uma reescrita do venerável xCAT 1.3 e como tal, há recursos que precisam ser alinhados.
• Como muitas ferramentas de software livre, a documentação poderia ser melhorada.

Há várias outras soluções de gerenciamento de cluster e nós poderíamos facilmente ter a discussão Emacs vs. vi sobre o tópico. Mas nós simplesmente encerraremos com isso: Dê uma chance ao xCAT se estiver procurando idéias ou algo melhor.

7. Utilize Soluções de Monitoramento de Software Livre

No ano passado, na SC'07, nos encontramos com diversas laboratórios de nível superior nos EUA para discutir o difícil problema do monitoramento de um cluster Linux. Isso levou a algumas chamadas no início de 2008 para discutir esse problema. O monitoramento é difícil por várias razões:

• Conforme o cluster fica maior, o dado coletado é maior e o desempenho pode ser sentido na máquina que recebe informações monitoradas. Por exemplo, se houver 2.000 máquinas e cada uma estiver enviando métrica para um nó de infraestrutura, o nó pode ficar enfraquecido e deixá-lo imaginando se ele está respondendo.
• Coletar dados com agentes em nós de cálculo pode sugar a memória e ciclos de CPU a partir das tarefas do usuário. Muitas lojas desejam que não haja agente nos nós porque isso reduz o desempenho de aplicativos. Encontrar o equilíbrio requer concessões: Compensa ter os ciclos de CPU capturados para obter os dados?
• Nós não vimos uma ferramenta escalável que ligue tarefas do usuário com o desempenho da máquina para traçar o perfil de tarefas de uma forma que seja utilizável e visualmente atraente.
• Não há nenhuma ferramenta que faça isso exatamente como você gostaria que fosse feito. Isso é o que talvez seja mais impressionante sobre esse espaço: As ferramentas utilizadas estão incompletas e deixam de fazer pelo menos algo que todos desejariam. A maioria dos administradores utiliza uma combinação de um ou dois produtos de gerenciamento. Quando vemos produtos que prometem monitorar o seu cluster que ultrapassam todas as outras soluções ficamos céticos: Cada cluster é diferente e nenhum tamanho se ajusta a todos. O monitoramento customizado parece ser o único caminho fora disso.

Portanto, dada a complexidade, aqui está como alguns dos administradores mais preguiçosos que conhecemos estão resolvendo o problema.

A solução mais comum que notamos em grandes lojas de cluster (incluindo universidades e laboratórios do governo importantes) foi utilizar Nagios para alerta e Ganglia para monitoramento. Entre essas duas ferramentas muito customizáveis um administrador pode obter ótimo insight nas inúmeras coisas que acontecem no cluster. Ganglia comprovou escalar extremamente bem.

Mas também existem outros pontos de vista. Na USC, Garrick Staples escreveu pbstop como um plug-in para TORQUE para visualmente verificar o que cada tarefa está fazendo e onde ela está em execução. Ele diz que esse é todo o monitoramento de que ele precisa e não utiliza mais nada.

As ferramentas de monitoramento de software livre mais conhecidas que vimos utilizadas pela comunidade de cluster scale-out são:

• Nagios.
• Ganglia.
• Cacti.
• Zenoss.
• CluMon.

Podemos dizer que muitas dessas ferramentas por sua vez fazem grande uso da RRDtool em sua implementação. O CluMon também utiliza o Performance Co-Pilot (PCP) abaixo do qual também é bem conhecido. O xCAT terá suporte para o Ganglia e o PCP em um release futuro.

Para recapitular, o administrador de cluster Linux preguiçoso sabe que

• O monitoramento não tem uma solução "um tamanho se ajusta a tudo". Monitoramento significa diferentes coisas para diferentes pessoas. Algumas pessoas estão interessadas apenas no alerta de máquina, outras em métrica de desempenho, outras em traçado de perfil de tarefa e outras simplesmente desejam saber se determinados serviços ou aplicativos estão em execução.
• A customização será diferente em diferentes sites e em diferentes clusters dentro dos mesmos sites.
• As concessões entre o que está sendo monitorado, para o que isso é utilizado e quais recursos isso requer precisam ser pesadas cuidadosamente.

8. Controle/Gerencie Usuários com um Planejador de Enfileiramento

O administrador preguiçoso sabe que os usuários são a raiz de todos os problemas. Impedir que os usuários tenham poderes ou permissões raiz é, portanto, extremamente importante. É possível ir além disso: Deve-se fazer o possível para manter os usuários longe de sua máquina.

Sistemas de enfileiramento fornecem essa funcionalidade: Um usuário envia uma tarefa e o sistema de enfileiramento decide em quais nós ela será executada. A menos que os usuários estejam executando um trabalho, eles devem ficar longe da máquina.

Os sistemas de enfileiramento conhecidos de hoje incluem algum pagamento por produtos como: LSF e PBS Pro. Esses produtos são utilizados por muitos clientes comerciais, bem como laboratórios do governo e universidades. Para muitos sistemas, planejar soluções de software livre como TORQUE e SLURM funciona muito bem.

Nós executamos um truque com TORQUE acoplado com o planejador Maui para manter nossos usuários longe do cluster a não ser que eles estejam executando uma tarefa. Em Linux, isso é feito primeiro configurando o arquivo /etc/security/access.conf de forma que somente root possa efetuar login e ninguém mais tenha permissão. Por exemplo, em cada nó se você executar o comando:

echo "-:ALL EXCEPT root:ALL" >>/etc/security/access.conf

então, apenas root poderá efetuar login nessa máquina. Em seguida, crie um script de prólogo TORQUE que permite ao usuário efetuar login que executa algo como isso:

perl -pi -e "s/:ALL$/ $USER:ALL/" /etc/security/access.conf

(Sugestão: A variável $USER é a segunda variável que é passada ao script de prólogo pelo TORQUE quando o script é executado.) Como o usuário root executa o script de prólogo, o usuário terá permissão de efetuar login no cluster. Quando a tarefa estiver concluída, um script de epílogo é executado que remove o usuário de /etc/security/access.conf de forma que ele não possa mais efetuar login no nó perl -pi -e "s/ $USER\b//g" /etc/security/access.conf. Isso impede que os usuários causem impacto um no outro.

Vimos problemas de "desempenho" em clusters que não estão relacionados com a máquina; o problema real é que múltiplos usuários executam na mesma máquina e as tarefas que eles executam cada uma requer 100 por cento da CPU.

Não é segredo que o gerenciamento de usuários é imperativo. Mas o que é sempre negligenciado na resolução de problemas simples é que os próprios usuários estão criando o problema. Sugerimos enfaticamente que os usuários sejam mantidos longe do sistema a menos que entrem nele através de um ambiente controlado como um planejador de recursos. Além disso, nós recomendamos que a própria rede de clusters (o gerenciamento de gigabits ou a rede de usuários) seja separada do resto da corporação our da WAN do campus com apenas determinados nós de usuário fornecendo acesso de frente.

9. Avaliação de Desempenho! Encontre Problemas de Desempenho antes Que Eles Encontrem Você

A última coisa com a qual você deseja tratar é um comportamento incendiário de máfia ameaçando queimar sua aldeia porque o desempenho é fraco e os resultados estão incorretos. Portanto, tenha em mente que com muita frequência, diagnósticos de hardware são as únicas provas decisivas ao determinar o mérito do cluster, mas diagnósticos de hardware podem pintar um quadro incompleto.

Diagnósticos de hardware são geralmente de aprovação/falha com um limite definido pelo fornecedor -- o seu limite pode ser mais alto ou mais baixo. Se um teste de diagnóstico de hardware falhar, então, você realmente tem um problema; entretanto, nenhuma falha não significa que não haja problemas.

Aqui estão alguns problemas que encontramos que tiveram um impacto mensurável no desempenho com sistemas que aprovaram diagnósticos do fornecedor:

• Erros de memória de bit duplo.
• Erros de memória de bit único.
• Erros de paridade de SRAM.
• Erros de barramento de PCI.
• Erros numéricos.
• Erros de cache.
• Erros de disco.
• Inconsistências de desempenho.

Muitas vezes existem problemas que não estão relacionados com o hardware, mas em vez disso com o software. Aplicativos, bibliotecas, compiladores, firmware e qualquer parte do sistema operacional podem ser a origem de muitos problemas não detectados pelo diagnóstico de hardware. Diagnósticos de hardware muitas vezes não são executados no mesmo ambiente de tempo de execução que os aplicativos e não sobrecarregam os subsistemas da mesma maneira que aplicativos -- então, problemas criados pelo software serão perdidos.

É claramente necessário executar algum tipo de carga de trabalho relevante com seu ambiente operacional para verificar se o seu cluster realmente pode fazer um bom trabalho. Isso pode ser realizado executando algumas avaliações de desempenho aceitas pelo segmento de mercado. O propósito da avaliação de desempenho não é obter os melhores resultados, mas obter resultados consistentes, repetíveis, precisos que também são os melhores resultados.

Como saber se os resultados são os melhores? Um cluster pode ser dividido nos seguintes subsistemas principais:

• Memória.
• CPU.
• Disco.
• Rede.

Seu fornecedor de hardware deve ter dados da avaliação de desempenho determinando o desempenho de Memória, CPU (FLOPS), Disco e Rede.

Como Saber se os Resultados São Consistentes?

Estatísticas. Cada avaliação de desempenho é executada uma ou mais vezes por nó (ou conjunto de nós para testes de multinós) e, em seguida, o melhor representante de cada nó (ou conjunto de nós) é agrupado junto e analisado como uma população única. Os resultados não são tão interessantes como a forma da distribuição dos resultados. A evidência empírica para todas as avaliações de desempenho neste artigo sugere que elas todas deveriam formar uma distribuição normal. Uma distribuição normal é a curva de sino clássica que aparece tão frequentemente em estatísticas. Ela é a soma de variáveis menores, independentes (podem ser inobserváveis), distribuídas identicamente ou eventos aleatórios.

Avaliações de desempenho também possuem muitas variáveis menores, independentes (podem ser inobserváveis) distribuídas identicamente que podem afetar o desempenho, como:

• Processos pequenos conflitantes.
• Troca de contexto.
• Interrupções de hardware.
• Interrupções de software.
• Gerenciamento de memória.
• Planejamento de processo/encadeamento.
• Raios cósmicos.

Essa variável pode ser inevitável, mas elas são uma parte da origem de uma distribuição normal.

Avaliações de desempenho também podem ter variáveis nãodistribuídas identicamente e observáveis que podem afetar o desempenho:

• Processos grandes conflitantes.
• Configuração da memória.
• Versão e configurações do BIOS.
• Velocidade do processador.
• Sistema operacional.
• Tipo de kernel (como NUMA vs SMP vs UNI) e versão.
• Memória inválida (como ECCs excessivos).
• Revisões do conjunto de chips.
• Hyperthreading ou SMT.
• Processos conflitantes não-uniformes (como httpd em execução em alguns nós, mas não em outros).
• Versões de biblioteca compartilhada.

Essas variáveis são evitáveis. Inconsistências evitáveis podem levar a distribuições multimodais ou não-normais e podem ter um impacto mensurável no desempenho do aplicativo.

Com um objetivo de resultados consistentes, repetíveis e precisos, é melhor iniciar com o menor número possível de variáveis. Inicie com avaliações de desempenho únicas como STREAM. Se todas as máquinas possuem resultados de STREAM semelhantes, então a memória pode ser descartada como um fator com outras anomalias de avaliação de desempenho. Em seguida, vá até as avaliações de desempenho do processador e do disco, então, até as duas avaliações de desempenho de dois nós (paralelas) e, em seguida, até as avaliações de desempenho de multinós (paralelas). Após cada avaliação de desempenho mais complicada, execute uma verificação para resultados consistentes, repetíveis e precisos antes de continuar.

No esboço a seguir está um caminho que recomendamos (a avaliação de desempenho relata o desempenho dos componentes em negrito).

• Avaliações de desempenho de nó único (serial):
  1. STREAM (MBps da memória)
  2. NPB Serial (FLOPS de uniprocessador e memória)
  3. NPB OpenMP (FLOPS de multiprocessador e memória)
  4. Memória Compartilhada do HPL MPI (FLOPS de multiprocessador e memória)
  5. IOzone (MBps do disco, memória e processador)
• Avaliações de desempenho paralelas (apenas para sistemas MPI):
  1. Ping-Pong (microseg e MBps de interconexão)
  2. NAS Parallel (FLOPS de multi-nós, memória e interconexão)
  3. Memória Distribuída do HPL MPI (FLOPS de multinós, memória e interconexão)

Espere, isso parece trabalho demais!

Isso é, mas também é necessário se planeja ser preguiçoso mais tarde. Felizmente nós temos as ferramentas e a documentação para tornar isso fácil. Alguns dias de planejamento adiantado podem economizar semanas de frustração posteriormente. Falaremos sobre essas ferramentas e gráficos em um artigo futuro; também serão publicados como parte de um futuro xCAT RPM que aumentará grandemente a produtividade.

10. Gerencie a Comunicação do Administrador de Cluster

Logo que coletar informações sobre um sistema, elas devem ser armazenadas em algum local útil para que o resto da equipe do cluster possa acessá-lo facilmente. Gostaríamos de lhe dar as boas-vindas para o ano 2000 -- os documentos em Word ou Excel não são bons e nem essa é a maneira de fazer isso com eficácia. A prática mais produtiva vista para isso é configurar um wiki interno. Isso é porque o administrador preguiçoso fica cansado de responder as mesmas perguntas sem parar. Em vez de ter que procurar ou executar algum comando para dar uma resposta, ele simplesmente diz: "Verifique o wiki." E sua tarefa está concluída.

Cada site deve manter um wiki que contém todas as informações sobre o cluster pelo qual geralmente perguntam, como:

• Um log de alterações no sistema incluindo quando a ação administrativa foi executada no cluster.
• Inventário de cluster: Versões de firmware, modelos, números de série, números de nós no cluster, tipo de processador, memória.
• Links para bilhetes de suporte aberto com o fornecedor e onde obter atualizações.
• Documentação para tarefas comuns utilizando gerenciamento de software.
• Informações sobre como imagens do S.O. são criadas.

Em resumo: O wiki devem ter informações suficientes de forma que se alguém fizer uma pergunta sobre o cluster o administrador precisa apenas dizer "Verifique o Wiki." Por sua vez, a qualquer hora que você fornecer a alguém uma resposta para algo que não esteja no wiki, deve informá-lo de que precisa retribuir por todo o conhecimento que você lhe forneceu no wiki. Além disso, é bom para a agitação no pessoal a qual é a realidade do selvagem mundo de TI.

Por que um wiki é melhor que outras formas de documentação?

• Wikis são editáveis em um local central e o controle de acesso pode ser fornecido a pessoas que precisam dele. Nós vimos documentos que residem em um repositório de compartilhamento, mas para visualizá-los, é preciso primeiro navegar para esse repositório, em seguida, salvar em sua unidade de disco rígido e depois abrir. Ineficaz. Um link é mais rápido e menos frustrante para chegar nele.
• Gravar informações em um documento ou planilha Word é estático e não é tão fácil para editar, salvar novamente e enviar revisões. Sem mencionar que vemos demasiadas repetições do mesmo documento por perto e as pessoas não percebem se têm a versão mais recente ou não. Especialmente quando mais de uma pessoa o está editando. De fato: Documentos ativos duram mais em wikis.

Configurar um wiki é extremamente fácil. Nós utilizamos o MediaWiki. Ele é gratuito, fácil de obter e fácil de instalar e configurar. (Consulte a barra lateral.)

A sintaxe do wiki é bem mais fácil que HTML e existem muitos links úteis na Web que mostram como utilizá-la. Há também boas extensões que é possível obter para realçar a sintaxe de código em perl ou bash se esse é o utilizado.

Encontramos pouca resistência em organizações quando propomos um wiki e esperamos que ele o torne mais preguiçoso instalando um.

11. Procure Maneiras para Tornar-se Mais Preguiçoso

Frequentemente vemos pessoas nos negócios de cluster fazendo coisas da maneira que fazem porque essa é a maneira que sempre fizeram. Nós pensamos que essa é uma boa maneira para uma loja de cluster Linux perder talento e obter o mínimo de trabalho do seu cluster. Mudança é o nome do jogo e novas idéias aparecem frequentemente.

Naturalmente, não esperamos que ninguém esteja apto a investigar cada idéia que surge em seu caminho, mas familiarizar-se com novas tendências é algo que distingue os bons administradores dos medíocres. Tendo isto dito, nesse espaço de rápida movimentação, provavelmente ninguém pode saber algo sobre todas as coisas e muito poucos sabem tudo sobre alguma coisa. Mas bons administradores de cluster sabem algumas coisas muito bem, até testaram mais coisas e fazem perguntas sobre coisas sobre as quais não se inteiraram.

Portanto, se alguém começa a conversar sobre algo desconhecido, o administrador Linux preguiçoso fará uma pergunta porque é muito preguiçoso para ir embora e utilizar seu mecanismo de procura favorito para encontrar informações sobre isso. Os administradores de cluster Linux mais assustadores são os tipos que nunca fazem perguntas. O administrador de cluster Linux preguiçoso não tem medo de dizer que não sabe algo. Ele confia em sua experiência de que se não sabe isso, alguém mais na sala também não sabe.

Hoje, há grandes coisas acontecendo no mundo do gerenciamento de clusters Linux. As mais interessantes que nós já vimos são:

1. Mais de um turno para computação sem preservação de estado. Facilita a administração de imagens e a manutenção de nós em sincronização.
2. Olhar os clusters a partir da perspectiva do datacenter. Isso significa levar em conta a energia e o resfriamento, assim como o resultado final em termos de três ou mais anos em oposição apenas ao custo de aquisição.
3. Eficiências de resfriamento líquido em oposição ao resfriamento a ar. Você sabia que o resfriamento líquido é 90 por cento mais eficiente que o resfriamento a ar?
4. Gerenciamento adaptável. Esse é onde o sistema de enfileiramento pode fazer provisão de nós on demand. Essa é a computação em nuvem verdadeira e nós demonstramos isso com Moab e xCAT. Essa é a etapa final do caminho para ociosidade completa.

Resumo

Se este artigo tiver feito seu trabalho, então você deve agora ter idéias de como pode realizar menos trabalho e ter melhor controle de seu ambiente de cluster Linux existente e planejar o seu próximo trabalho. Nós estamos confiantes de que as idéias e práticas que apresentamos neste artigo contribuem para a melhor utilização de cluster, uma ciência mais profissional em torno dele e uma equipe administrativa de cluster mais enxuta e eficiente.

Ter menos pessoas e menos problemas significa menos reuniões, menos trabalho e mais tempo para WoW, contar carneirinhos, dormir ou fazer quaisquer que sejam suas buscas preguiçosas.

Recursos

Aprender

• As dicas 8 e 10 do artigo "Lazy Linux: 10 Truques Essenciais para Administradores" (developerWorks, Julho de 2008) documentam várias técnicas de programação de script da linha de comando que gostamos de utilizar frequentemente.
  
  
• Consulte Mais dicas de Linux no developerWorks.
  
  
• Alguns dos recursos que mencionamos neste artigo:
  • A lista dos Top500 Sites de Supercomputação tem listado os computadores mais rápidos do mundo desde 1993.
  • Acredito que mencionamos a Conferência de 2007 de Supercomputação. (Existe pelo menos uma dessas gemas a cada ano.)
  
  
• Na zona Linux do developerWorks, encontre mais recursos para desenvolvedores Linux (incluindo desenvolvedores que são novos para Linux) e varra nossos artigos e tutoriais mais conhecidos.
  
  
• Consulte todas as dicas de Linux e tutoriais de Linux no developerWorks.
  
  
• Fique atualizado com eventos técnicos e Webcasts do developerWorks.
  
  

Obter produtos e tecnologias

• Aqui está onde obter alguns dos recursos mencionados neste artigo:
  • Rocks é uma distribuição de cluster Linux de software livre que permite aos usuários finais construir facilmente clusters computacionais, terminais de grade e paredes de exibição com mosaico de visualização. O grupo tem um objetivo: Tornar os clusters fáceis.
  • OSCAR (Open Source Cluster Application Resources) permitem aos usuários, independentemente de seu nível de experiência com um ambiente *NIX, instalar um cluster HPC do tipo Beowulf.
  • Perceus é a próxima geração do kit de ferramentas corporativo e de fornecimento de cluster criado pelos desenvolvedores do Warewulf.
  • xCAT (eXtreme Cluster Administration Toolkit) é uma ferramenta de gerenciamento de computação distribuída escalável e de fornecimento que fornece uma interface unificada para controle de hardware, descoberta e implementação disco cheio/ espaço livre em disco do S.O.
  • Nagios é um host e monitor de serviço projetado para informá-lo sobre problemas de rede antes que seus clientes, usuários ou gerentes o façam -- ele foi projetado para Linux, mas funciona bem sob a maioria das variantes do *NIX.
  • Ganglia é um sistema de monitoramento distribuído escalável para clusters e grades HPC que é baseado em um design hierárquico com destino em federações de clusters.
  • pbstop é uma ferramenta de monitoramento de ncurses e de administrador distribuída dentro do PBS (Portable Batch System) do perl e é utilizada pelos administradores dos maiores clusters do mundo.
  • TORQUE é um gerente de recurso de software livre que fornece controle sobre tarefas em lote e nós de computação distribuída, um esforço da comunidade baseado no projeto do *PBS original.
  • Cacti é uma solução gráfica de rede completa projetada para aproveitar a energia do armazenamento de dados e da funcionalidade gráfica da RRDTool; ele inclui um poller rápido, modelagem gráfica avançada, múltiplos métodos de aquisição de dados e recursos de gerenciamento do usuário prontos para uso.
  • Zenoss entrega soluções de gerenciamento de TI de software livre comercial.
  • CluMon é um sistema de monitoramento de cluster desenvolvido no Centro Nacional para Aplicativos de Supercomputação a fim de manter o controle de seus superclusters Linux; ele é um sistema ajustável que pode ser feito para funcionar para quase qualquer conjunto de máquinas Linux.
  • RRDtool é um sistema de software livre, de criação de log de dados de alto desempenho e gráfico para dados de série de tempo.
  • Co-piloto de Desempenho fornece uma estrutura e serviços para suportar monitoramento de desempenho e gerenciamento de desempenho em nível de sistema; SGI forneceu uma versão de software livre em 2000.
  • SLURM, o "gerente de recurso altamente escalável" (e um refrigerante popular baseado em worm no cartum Futurama), é um gerente de software livre projetado para clusters Linux de todos os tamanhos que fornece três funções chave -- ele aloca acesso exclusivo e/ou não-exclusivo para recursos; ele fornece uma estrutura para iniciar, executar e monitorar trabalho em um conjunto de nós alocados; e ele arbitra a contenção para recursos gerenciando um fila de trabalhos pendentes.
  • Moab Workload Manager é um planejador de tarefas baseado em política e mecanismo de evento que ativa a computação baseada em utilitário para clusters.
  
  
• Solicite o SEK para Linux, um conjunto de dois DVDs que contém o software de período experimental IBM mais recente para Linux a partir do DB2®, Lotus®, Rational®, Tivoli®e WebSphere®.
  
  
• Com o Software de período experimental IBM, disponível para download diretamente do developerWorks, construa seu próximo projeto de desenvolvimento em Linux.
  
  

Discutir

• Envolva-se com a comunidade do developerWorks através de blogs, fóruns, podcasts e espaços.
  
  

Sobre os autores

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• 1. Não Reinvente a Roda
• 2. Utilize Software Livre
• 3. Automatize Tudo
• 4. Projete para Escala e Planeje Ser Preguiçoso Desde o Início
• 5. Projete para o Gerenciamento de Hardware
• 6. Bom Software de Gerenciamento de Cluster Evita que Você Cave Poços Com Colheres de Chá
• 7. Utilize Soluções de Monitoramento de Software Livre
• 8. Controle/Gerencie Usuários com um Planejador de Enfileiramento
• 9. Avaliação de Desempenho! Encontre Problemas de Desempenho antes Que Eles Encontrem Você
• 10. Gerencie a Comunicação do Administrador de Cluster
• 11. Procure Maneiras para Tornar-se Mais Preguiçoso
• Resumo
• Recursos
• Sobre os autores
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais