7 de outubro de 2011

Script, "oneliner", para teste de performance de sistemas de arquivos distribuidos

Muitos de vocês já devem ter se deparado com sistemas de arquivos distribuídos. Diferente de sistemas de arquivos locais, como ext3, NTFS, XFS, JFS, Fat32, e etc, os sistemas de arquivos distribuídos (ex: IBM GPFS, PanFS, PVFS2) se utilizam de vários servidores conectados à um disco comum entre eles (ou cada um à um disco dedicado) e conseguem atingir níveis de performance muito maiores que os esperados por sistemas de arquivos tradicionais (até mesmo quando comparando com sistemas como NFS e CIFS).

Existem muitas soluções que se beneficiam destes sistemas de arquivos, tais como: SAP Netweaver, SAP BW Accelerator, Web Servers (apache, tomcat, etc), e-mail (Exchange, Lotus Notes), Servidores de Arquivos, Computação de Alta Performance (HPC), Computação em Nuvem (Cloud Computing) e etc.

Costumeiramente, quando estou trabalhando em um cliente e quero demonstrar a performance deste sistema, uso um script básico para gerar uma carga neste sistema de arquivos. No mundo Linux temos uma terminologia que, quando escrevemos um mini-script na linha de comando, e não em um arquivo, chamamos, em inglês, de "oneliner script", ou seja, "script em uma linha".

Para podermos rodar este script que uso, basta:

1. Criar um arquivo com a lista de servidores (aqui será o nodes.list) e copiá-lo para os outros servidores

2. Garantir que há comunicação entre eles sem a necessidade do uso de senha para um usuário (veja no meu outro post como fazer isso)

3. Garantir que o sistema de arquivos distribuídos está montado (aqui será o diretório /gpfsFS1)

4. Rodar o script abaixo:

# for i in `cat /tmp/nodes.list`; do ssh -f $i 'for j in `cat /tmp/nodes.list`; do ssh -f $j dd if=/dev/urandom of=/gpfsFS1/$j.$(hostname).wrk bs=1048576 count=4000 ; done' ; done

onde temos:
if=/dev/urandom   :   o local onde vamos buscar informações para gerar um arquivo de teste. Pode ser também o /dev/zero, se quiser, ou /dev/random

of=/gpfsFS1/         :   o local onde vamos gravar os arquivos de teste. Importante que seja o diretório onde o seu sistema de arquivos paralelo está montado

bs=1048576          :    o tamanho do block size do seu sistema de arquivos. Aqui coloquei como 1M (ou 1048576 bytes)

count=4000          :     a quantidade de block sizes que iremos gravar, aqui sendo 4000. Ou seja, block size * count = tamanho do arquivo final. No caso acima, 1048576 * 4000 = 4Gbytes

O script irá ler o arquivo nodes.list e executar, para cada linha (cada servidor), um outro loop. Neste loop aninhado, ele irá, a partir de cada servidor da lista, acessar o outro servidor e mandar escrever um arquivo de 4GBytes no diretório do sistema de arquivos distribuídos.

Veja que, como há um loop aninhado, serão escritos muitos arquivos ao mesmo tempo e todos terão um total de 4Gbytes, ou seja, dependendo da quantidade de servidores que você tiver na lista o tamanho total de uso do sistema de arquivos poderá ser bem grande.

O paramêtro -f do ssh diz que é para cada interação ssh acontecer imediatamente e não esperar o término da execução do comando para voltar ao prompt. Ou seja, ao enviar o comando o ssh já irá retornar ao prompt fazendo com que o loop já envie o próximo comando sem esperar que o primeiro seja concluído. Dessa forma teremos, em paralelo, todos os processos escrevendo ao mesmo tempo e estressando o nosso sistema de arquivos paralelo.

Para medir a performance do sistema, use a sua ferramenta de análise preferida (seja uma linha de comando como o 'sar -b' - do pacote sysstat - ou seja uma ferramenta gráfica - por exemplo IBM Tivoli Monitoring).

obs: depois eu escrevo um post sobre como monitorar e analisar a performance de sistemas de arquivos, e como otimizá-los. ;)

19 de setembro de 2011

Resetando a contagem de alocação (alloc_count) no NIM

Muitas vezes já me deparei com este "problema" ao usar o NIM: um recurso aloca um lpp_source e por algum motivo não consegue desalocar este lpp_source, deixando o mesmo com alloc_count=1.

root@xcat01 # lsnim -l aix6106_lpp_source
aix6106_lpp_source:
   class       = resources
   type        = lpp_source
   arch        = power
   Rstate      = ready for use
   prev_state  = verification is being performed
   location    = /install/nim/lpp_source/aix6106_lpp_source
   simages     = yes
   alloc_count = 1
   server      = master

Uma vez que isso acontece, e tenta-se fazer alguma operação neste lpp_source, por exemplo adicionar novos pacotes, um erro é retornado dizendo que o recurso já está alocado para outro cliente.

xcat01@root # nim -o update -a packages=rsync-3.0.6-1.aix5.3.ppc.rpm -a source=/opt/media/xcat-dep/6.1 aix6106_lpp_source

0042-001 nim: processing error encountered on "master":
   0042-061 m_update: the "aix6106_lpp_source" resource is currently
        allocated for client use


Enquanto este erro acontecer não será possível, por exemplo, adicionar novos pacotes ao seu lpp_source. Uma alternativa que se pode usar para resolver este problema é tentar achar o recurso que está usando este lpp_source e desalocar o lpp_source deste recurso. Para isso basta fazer:

lsnim -l $CLIENT

onde $CLIENT é o nome do cliente que você suspeita que está alocando o recurso, e ver se ele está alocando o recurso (para analisar todos os seus clientes, sugiro criar um script para recursivamente analisar todos).

Ao verificar qual cliente está alocando o lpp_source pode-se desalocar o recurso da seguinte maneira:

nim -o deallocate -a force=yes $CLIENT

E com isso podemos voltar a fazer operações no lpp_source.

Outra maneira é forçar o reset do alloc_count para zero. Para isso precisamos usar um comando que é pouco conhecido (m_chattr):

#  /usr/lpp/bos.sysmgt/nim/methods/m_chattr -a alloc_count=0 aix6106_lpp_source

E com isso teremos forçado o reset do contador e agora podemos voltar a fazer operações em cima deste recurso.

root@xcat01 # lsnim -l aix6106_lpp_source
aix6106_lpp_source:
   class       = resources
   type        = lpp_source
   arch        = power
   Rstate      = ready for use
   prev_state  = verification is being performed
   location    = /install/nim/lpp_source/aix6106_lpp_source
   simages     = yes
   alloc_count = 0
   server      = master

xcat01@root # nim -o update -a packages=rsync-3.0.6-1.aix5.3.ppc.rpm -a source=/opt/media/xcat->

/install/nim/lpp_source/aix6106_lpp_source/RPMS/ppc/rsync-3.0.6-1.aix5.3.ppc.rpm

O NIM é um recurso muito interessante e útil do ambiente AIX, então espero que esta dica ajude-os a se tornar um pouco mais "expert" nessa ferramenta :)

14 de abril de 2011

Desenvolvendo sua carreira em IT: parte 1

O intuito desta série não é, de forma alguma, "empurrar goela abaixo" um caminho de desenvolvimento de uma carreira em IT. Na verdade, esta série é mais para que eu possa compartilhar, com quem queira, alguns dos caminhos que eu venho tomando para o desenvolvimento da minha carreira em IT.

Logo de início, a primeira dica, você tem que decidir o que quer para os próximos anos que vem pela frente. Quando se está iniciando a carreira (nos primeiros 5 anos, geralmente) é difícil querer definir uma estratégia para os próximos 10 a 15 anos porque, normalmente, não se tem a experiência necessária para definir isso (experiência aqui significando visão do tamanho e diversidade deste mercado!).

Então o conselho é o seguinte: tente imaginar metas para a sua vida em um futuro próximo, digamos nos próximos 2 a 3 anos. Imagine se quer ser um desenvolvedor de software, ou um arquiteto de sistemas, ou um administrador de redes e/ou servidores, e etc. Uma vez que fizer isso, dê foco às certificações da sua área. Exemplo: se for uma administração de redes vá fazer um CCNA e/ou CCNP, se for administrador de servidores faça um MCSA e LPIC-2, e assim por diante.

Além de pensar na carreira em si, também pense nos seus objetivos pessoais. Muitas vezes focamos tanto na carreira que não nos damos conta de que abdicamos nossa vida pessoal pelo desenvolvimento da nossa carreira. Para alguns, isto não é tão problemático. Para outros, isso é um caos! Ou seja, tente entender qual é o balanço adequado entre o seu "eu" pessoal e o seu "eu" profissional. Isto é importante pois, como em todos trabalhos, você será cobrado, exigido, pressionado, e essa tensão toda pode explodir no seu lado pessoal. O problema é que isso pode levar uma pessoa a entrar em depressão e atrapalhar não só a vida privada, mas também a profissional. E uma vez que isso acontece, se não for identificado devidamente e procurada uma ajuda para sair deste turbilhão, tanto a sua vida privada como a profissional irão ficar estagnadas ou até regredir.

Então, palavras chaves: foco e objetivo. Tenha metas claras. Se não souber, ou estiver com dificuldades de definir, procure ajuda com os amigos, seus pais, e também com os colegas de trabalho e gerentes da compania. O importante é conversar com pessoas que estejam em momentos, passos, fase, posições, mais avançadas do que a que você se encontra hoje. Lembre-se: essas pessoas em algum momento tiveram que passar por onde você está hoje, e irão entender a sua posição. Além disso, você será respeitado por estar querendo se desenvolver e crescer, e isso também irá lhe ajudar no seu caminho para atingir o seu objetivo.

Nos próximos posts vou tentar mostrar alguns caminhos que eu tomei para chegar na posição que estou hoje. Depois vou tentar consolidar algumas idéias e objetivos que estou pensando para o desenvolvimento do futuro da minha carreira.

Espero que este post veja a ajudar aos leitores!

31 de março de 2011

Gerencie seus servidores pelo iPhone / iPad (iOS em geral)

É, pode-se falar o que quiser da IBM, mas não dá pra dizer que ela é uma empresa retrógada. Além de várias inovações que já fazem parte do nosso cotidiano há muito tempo, ela continua, apesar dos seus 100 anos, inovando e muito!

Existem pessoas que já usam, em seus tablets e/ou smartphones, aplicativos como SSH e/ou VNC, mas estes sempre tem o problema de que estão trazendo a tela inteira do servidor para uma telinha pequena de um tablet (mesmo quando estamos falando de um iPad, a tela é pequena e não temos o teclado adequado). Fora que estas aplicações permitem que você gerencie o sistema operacional em si e não o hardware propriamente dito (apesar de que você pode usar as ferramentas do sistema operacional para gerenciar o hardware, mas estará limitado pelas funções das mesmas)

Agora, e se fosse oferecido um software que já é voltado para gerência adequada do hardware? É aí que entra mais uma inovação da IBM: a Big Blue lançou um aplicativo free (sem custo) para o iOS (iPhone, iPad, iPod Touch) que gerencia seus servidores IBM System x & Bladecenter.

Além de poder verificar o status do hardware (ligado/desligado, erros e etc), o usuário também pode ligar/desligar os servidores, mudar o dono da sessão de KVM, etc.

Esse tipo de aplicativo é interessante uma vez que permite administradores a terem acesso à um tipo de controle que costumeiramente só se tem quando se está fisicamente dentro de um datacenter.

Em um futuro próximo deverá existir suporte para Blackberry e Android, além do suporte ao chip de controle chamado Integrated Management Module (iMM), que é encontrado em toda a linha de servidores IBM System x.

Ah! E quem achou que parava por aí, enganou-se ;) Além deste aplicativo, já existe outro que é capaz de gerenciar um Blue Gene/P (máquina de milhares de núcleos de processamento da IBM).

Isso sim é inovação que melhora nossa qualidade de vida! Afinal de contas, nós administradores, agora poderemos dormir mais tranquilos e quando nos acionarem às 3AM só precisaremos pegar nossos smartphones e resolver o problema!

Saiba mais sobre este aplicativo neste link.

24 de fevereiro de 2011

Habilitando seu desktop / laptop como um router

Talvez não para todos mas, para nós que trabalhamos em vários datacenters diferentes, volta e meia nos deparamos com servidores que não são conectados diretamente à internet, nem usam um serviço de proxy para isso.

Mas, nestes casos, como fazer para se conectar à internet? Bom, caso o dono dos servidores (seu cliente) permitir, e você tiver uma conexão 3G ou WiFi disponivel no seu laptop, é muito simples usar o seu laptop como um "router" para acesso à internet.

Óbviamente que eu estou contando que você roda alguma distribuição de Linux, certo? ;)

Bom, para tornar o seu laptop/desktop em um router basta:

1. Habilitar o encaminhando de pacotes de uma interface para a outra no seu kernel
# cat 1 >/proc/sys/net/ipv4/ip_forward

2. Uma vez que isso foi feito, precisamos agora criar 2 regras no seu iptables. Porém, antes disso, verifique se o seu iptables não está configurado para ser um firewall (afinal, não queremos barrar os pacotes que chegarão no laptop do servidor)
# service iptables status

(se estiver rodando o mais simples é desligá-lo)
# service iptables stop

3. Ok, agora vamos configurar o iptables para permitir que os pacotes que venham do servidor sejam redirecionados para a interface conectada à internet e para permitir que os IP's que vem da "rede interna" sejam "mascarados" como um único IP de saída (NAT), respectivamente:
# iptables -A FORWARD -i eth0 -j ACCEPT
# iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE

onde eth0 é a interface da rede interna, onde o servidor está conectado, e wlan0 é a interface da rede externa, a qual está conectada à internet.

Pronto! O seu laptop está funcionando como um router. Agora basta que você garanta que no seu servidor o DNS está configurado:
# cat /etc/resolv.conf

Se o arquivo não conter um nameserver válido, pode ser adicionado o nameserver 8.8.8.8 que é um DNS público do Google.

E precisamos garantir que temos uma rota default apontando para o IP do nosso laptop/desktop:
# route add default gw <ip_laptop>

Se quiser testar, basta fazer um ping para algum site, como google.com, e ver se o nome está sendo resolvido e se o ping está sendo respondido.

4 de fevereiro de 2011

"O vôo é doméstico, mas o embarque é internacional". Faz sentido?

Santiago para o Rio de Janeiro. Com parada em São Paulo. Pergunta: internacional ou nacional?

Pois bem, parece que a resposta para essa pergunta não é tão simples quanto parece. Inicialmente vocês devem estar pensando que é um vôo internacional com conexão em São Paulo. Pois estão enganados, assim como eu também fui.

Tudo começou com a compra. Na verdade, o problema todo foi falta de comunicação.

Na empresa que trabalho temos que usar a American Express (AMEX) como nossa agência de viagens. Então, já que tinha que ir ao Chile à trabalho, liguei para a AMEX e pedi uma passagem ida e volta Rio de Janeiro / Santiago. A falta de comunicação já começou quando a atendente me disse que havia um assento de ida direto do Rio de Janeiro para Santiago, porém que a volta seria com conexão em São Paulo. A falta de comunicação foi que, na verdade, não era conexão em São Paulo mas sim um vôo de Santiago para São Paulo e um outro de São Paulo para o Rio de Janeiro.

Bom, até aí ninguém tem culpa a não ser a AMEX. Aliás, esta não foi a primeira vez que eles me fazem algo assim. Se fosse por mim, não usava o serviço deles pois além de tudo é caro. Mas como estou preso à políticas de trabalho, não tenho muita escolha...

O problema real foi quando, na volta, fui fazer o check-in em Santiago. A atendente da LAN, companhia que estava voando, me disse que minha bagagem estaria "checada" até São Paulo somente e que lá eu deveria retirá-la, passar na Alfandega, sair do terminal, passar no balcão da TAM, fazer o meu novo check-in (agora de SP pro RJ), e aí passar na polícia mais uma vez, e etc, etc... Ou seja, uma bagunça total. Resolvi então ir no balcão da TAM, que era o vôo de SP pro RJ e uma parceira da LAN. Lá na TAM me informaram tudo diferente: disseram que minha mala deveria estar despachada direto ao RJ, que eu não ia precisar fazer Alfandega em SP, que eu não ia sair do terminal e etc, etc....

Conclusão: após um vôo horroroso cheio de bebês e crianças berrando durante sa 4h de vôo, eu cheguei em São Paulo e tive que fazer todo o trâmite de passar pela polícia, Alfandega, ir ao check-in da TAM, despachar bagagem, passar polícia e etc... só que agora em um vôo doméstico.

Mas vocês acharam que isso tudo foi tranquilo e que acabou por aí, né? Mais uma vez enganados, como eu.

Após fazer o check-in na TAM, olhar minha passagem e ver em letras grandes INFRAERO DOMÉSTICO, tive que ir para o embarque INTERNACIONAL e passar pela polícia seguindo as regras internacionais. Daí resolveram implicar com a minha pasta de dente (em tubo de 125g) e com o creme de mãos que tenho (de 75g). A pasta de dente disseram que era acima de 100g (apesar de estar no fim) e que deveria ser descartada. E o creme me disseram que, por não estar em um plástico, também deveria ser descartado.

E você acham que eu ia deixar por aí? Hehehehe, se enganaram, mas dessa eu não me enganei ;)

Não deixei barato. Comecei a gastar minha salíva, afinal eu tinha ainda 1:30h pra embarcar, e disse que todos os outros locais internacionais que viajei, incluindo USA, nunca implicaram com a minha pasta de dente. E que o meu creme de mãos, apesar de não estar no saco plástico, não deveria ser jogado fora pois é de obrigação do aeroporto fornecer o saco plástico, assim como em todos os outros aerportos que já passei.

Bom, pra finalizar o melo-drama brasileiro, a porno-chanchada (que infelizmente de nudez não teve nada :P ), a polícia que inspecionou a minha bagagem disse:

"Eu vou fingir que não vi, mas só dessa vez..."

Esse é o Brasil que vai sediar a Copa do Mundo em 2014 e as Olímpiadas em 2016. Esse Brasil tem que tomar muito "toddynho" e leite ninho nos próximos anos, ou vamos sediar a comédia trágica de ser o único país a ser desclassificado após ser classificado!

1 de fevereiro de 2011

Suspend e HIbernate pararam de funcionar após upgrade do Ubuntu 10.10

Costumeiramente faço os upgrades do Ubuntu assim que estão disponíveis. O interessante dos updates do Linux, versus updates do Windows por exemplo, é que realmente vemos a diferença quando fazemos os updates. Seja uma função adicional, uma melhoria na performance, ou, no meu caso, um problema que aparece.

Após o fazer um update, por volta do dia 28/01/2011, meu Ubuntu 10.10 parou de funcionar a função de "suspend" e "hibernate".

O equipamento que uso é um Lenovo Thinkpad T400. Meu kernel é o 2.6.35-25-generic.

Inicialmente acreditei que era um problema da placa gráfica Intel Mobile 4 Series, mas logo descobri que não. Olhei em alguns logs, como o /var/log/pm-suspend.log assim como o /var/log/messages e o dmesg mas nenhum falava claramente sobre algum problema.

Porém quando eu tentava fazer o "suspend" ou "hibernate" uma mensagem sobre os módulos do Trusted Platform Module (TPM) aparecia na tela. Infelizmente era rápido demais para analisar corretamente a mensagem.

O que fiz então foi usar um comando muito útil para analisar os módulos de kernel do TPM: modinfo. Fiz o seguinte:

  1. Pesquisei se havia algum módulo do TPM carregado no meu sistema


     # lsmod |grep tpm

  2. Encontrei 3 módulos: tpm_tis, tpm_bios e tpm. Verifiquei com o modinfo se havia algum parametro que eu poderia passar para este módulo.
 
     # modinfo tpm
     # modinfo tpm_tis
     # modinfo tpm_bios

  3. Dos 3 módulos, somente o tpm_tis tinha um parâmetro para passar. E o parâmetro dizia o seguine na sua descrição: "itpm:Force iTPM workarounds (found on some Lenovo laptops)". Ou seja, provavelmente esse parametro me ajudaria (já que meu laptop é Lenovo).

  4. Criei o arquivo /etc/modprobe.d/tpm_tis.conf e adicionei a seguinte linha options tpm_tis itpm=1. O arquivo teve que ser criado para garantir que este parametro será passado todas as vezes que o meu sistema for carregado.

     # echo "options tpm_tis itpm=1" >/etc/modprobe.d/tpm_tis.conf 

  5. Depois foi só descarregar o módulo e carregá-lo novamente

     # modprobe -r tpm_tis && modprobe tpm_tis

Após este procedimento tudo voltou ao normal. Agora ao fechar o meu laptop, ele entra em "suspend". E se fica muito tempo assim, vai para o "hibernate". Do jeito que era antes! :-D

3 de janeiro de 2011

"Network error" com o Empathy (usando uma conta do MSN)

Recentemente, durante um dos updates do Ubuntu, meu Empathy parou de funcionar com o MSN. Na verdade, a conexão ficava esporádica, ou seja, haviam vezes em que o MSN conectava mas a maioria das vezes não conectava. A mensagem de erro que aparecia era:

"Network error"

Pesquisando um pouco na internet verifiquei que o problema possivelmente estava no protocolo 'telepathy-butterfly'. Esse protocolo é o substituto do python-msn, usado anteriormente pelo Empathy para se conectar ao serviço MSN. Na verdade, Telepathy é um pacote que implementa diversos protocolos para conexão com diversas redes, sendo o 'telepathy-butterfly' a biblioteca utilizada pelo Empathy.

Uma solução temporária é:

# killall telepathy-butterfly

e depois você deve ir no seu Empathy em Edit -> Accounts e escolher a conta MSN e desmarcar o 'Enabled' e depois remarcá-lo. Caso mesmo assim o seu MSN não volte a funcionar, vá em Chat -> Quit e abra novamente o Empathy depois de verificar se o telepathy-butterfly realmente não está mais carregado. Para verificar basta:

# ps auxww |grep telepathy-butterfly |grep -v grep

e se a saída deste comando não mostrar nenhum processo rodando, perfeito. Caso contrário, execute de novo o killall acima e reinicie o seu Empathy.

Como podem ver, esta não é uma solução final mas sim um paliativo. Já existe um aviso de bug aberto referente à este problema e espero que uma correção saia em breve.