Pós-graduação em Redes de Computadores

Estão abertas as inscrições para a Pós-graduação em Redes de Computadores da FABERJ, localizada na cidade de Campos dos Goytacazes/RJ

O curso tem carga horária de 384 horas e as aulas serão aos sábados de 15 em 15 dias.
As disciplinas do curso e as ementas estão disponíveis no site da faculdade.

Acessar o endereço abaixo para maiores informações:

http://www.faberj.edu.br/index.php/pos-graduacao/redes-de-computadores.html

Apresentação de Introdução ao Zabbix

Pessoal,

Está disponível no site do projeto Zabbix, uma apresentação online sobre essa ferramenta.
É uma introdução muito interessante sobre o Zabbix.
Para visualizar, acesso o endereço: http://www.zabbix.com/presentation.php

Fica a dia.

Monitorar servidor Apache pelo Zabbix

Estou com este post pronto deste 18/07/2012, porém esqueci de agendar a data da postagem e só agora, revisando meus posts, vi que este ainda não estava ativo. Mas agora ele está aí.

Outro dia estava procurando detalhes de como monitorar o servidor Apache pelo Zabbix e encontrei um texto na Wiki do Zabbix. No tópico da Wiki tem três métodos explicando como fazer o monitoramento do servidor Apache, dois com Python e um em bash script.

Na Wiki tem disponível o código do script e uma template para coletar os itens.

Eu modifiquei o script para tornar a consulta mais rápida usando fgrep e awk ao invés de dar um echo no arquivo temporário e logo em seguida usar grep e awk, como no script disponível na Wiki.

Crie o seguinte script com o nome apache.sh e salve onde achar necessário (eu coloco os meus scripts em /opt/zabbix/externalscripts/):

#!/bin/bash
host="localhost"
resposta=0
tmp="/opt/zabbix/tmp/apache_status"
pega_status=`wget --quiet -O $tmp http://$host/server-status?auto`
case $1 in
   TotalAccesses)
      $pega_status
      fgrep "Total Accesses:" $tmp | awk '{print $3}'
      resposta=$?;;
   TotalKBytes)
      $pega_status
      fgrep "Total kBytes:" $tmp | awk '{print $3}'
      resposta=$?;;
   Uptime)
      $pega_status
      fgrep "Uptime:" $tmp | awk '{print $2}'
      resposta=$?;;
   ReqPerSec)
      $pega_status
      fgrep "ReqPerSec:" $tmp | awk '{print $2}'
      resposta=$?;;
   BytesPerSec)
      $pega_status
      fgrep "BytesPerSec:" $tmp | awk '{print $2}'
      resposta=$?;;
   BytesPerReq)
      $pega_status
      fgrep "BytesPerReq:" $tmp | awk '{print $2}'
      resposta=$?;;
   BusyWorkers)
      $pega_status
      fgrep "BusyWorkers:" $tmp | awk '{print $2}'
      resposta=$?;;
   IdleWorkers)
      $pega_status
      fgrep "IdleWorkers:" $tmp | awk '{print $2}'
      resposta=$?;;
   WaitingForConnection)
      $pega_status
      fgrep "Scoreboard:" $tmp | awk '{print $2}'| awk 'BEGIN { FS = "_" } ; { print NF-1 }'
      resposta=$?;;
   StartingUp)
      $pega_status
      fgrep "Scoreboard:" $tmp | awk '{print $2}'| awk 'BEGIN { FS = "S" } ; { print NF-1 }'
      resposta=$?;;
   ReadingRequest)
      $pega_status
      fgrep "Scoreboard:" $tmp| awk '{print $2}'| awk 'BEGIN { FS = "R" } ; { print NF-1 }'
      resposta=$?;;
   SendingReply)
      $pega_status
      fgrep "Scoreboard:" $tmp | awk '{print $2}'| awk 'BEGIN { FS = "W" } ; { print NF-1 }'
      resposta=$?;;
   KeepAlive)
      $pega_status
      fgrep "Scoreboard:" $tmp | awk '{print $2}'| awk 'BEGIN { FS = "K" } ; { print NF-1 }'
      resposta=$?;;
   DNSLookup)
      $pega_status
      fgrep "Scoreboard:" $tmp | awk '{print $2}'| awk 'BEGIN { FS = "D" } ; { print NF-1 }'
      resposta=$?;;
   ClosingConnection)
      $pega_status
      fgrep "Scoreboard:" $tmp | awk '{print $2}'| awk 'BEGIN { FS = "C" } ; { print NF-1 }'
      resposta=$?;;
   Logging)
      $pega_status
      fgrep "Scoreboard:" $tmp | awk '{print $2}'| awk 'BEGIN { FS = "L" } ; { print NF-1 }'
      resposta=$?;;
   GracefullyFinishing)
      $pega_status
      fgrep "Scoreboard:" $tmp | awk '{print $2}'| awk 'BEGIN { FS = "G" } ; { print NF-1 }'
      resposta=$?;;
  IdleCleanupOfWorker)
      $pega_status
      fgrep "Scoreboard:" $tmp | awk '{print $2}'| awk 'BEGIN { FS = "I" } ; { print NF-1 }'
      resposta=$?;;
  OpenSlotWithNoCurrentProcess)
      $pega_status
      fgrep "Scoreboard:" $tmp | awk '{print $2}'| awk 'BEGIN { FS = "." } ; { print NF-1 }'
      resposta=$?;;
   *)
      echo "ZBX_NOTSUPPORTED"
esac
if [ "$resposta" -ne 0 ]; then
   echo "ZBX_NOTSUPPORTED"
fi
exit $resposta

Após copiar o script para a pasta desejada (eu coloco meus scripts utilizados pelo Zabbix em /opt/zabbix/externalscripts/), precisamos editar o arquivo de configuração zabbix_agentd.conf (no meu caso em /etc/zabbix/zabbix_agentd.conf) e adicionar no final do arquivo:

# Monitoramento Apache
UserParameter=apache[*],/opt/zabbix/externalscripts/apache.sh '$1'

Salve o arquivo e reinicie o servidor do agente do Zabbix.

O que acabamos de fazer foi incluir um monitoramento inexistente no Zabbix. Porém, a flexibilidade oferecida pelo Zabbix nos permite entregar apenas o resultado de um monitoramento, o restante ele faz (coleta, alarmes etc).

Explicando a configuração do UserParameter que acabamos de incluir no arquivo de configuração

O Zabbix irá executar o script apache.sh com o parâmetro que está cadastrado no item.
Por exemplo: Imagine que o item seja 'BytesPerReq'. Assim que o Zabbix for coletar o item, o script será executado com o parâmetro 'BytesPerReq' que executará a consulta na página de status do Apache e retornará apenas o valor do item que desejamos coletar.

Eu modifiquei a template disponível na Wiki do Zabbix, pois ela não tinha gráfico configurado. Para baixá-la, clique aqui.

Após baixar a template, basta exportar o e associar ao host que será monitorado.

Configurar apache para permitir a consulta dos dados

Não basta apenas configurar o Zabbix para que o monitoramento do servidor Apache funcione, é preciso liberarmos no arquivo de configuração (no meu caso /etc/httpd/conf/httpd.conf) do Apache o seguinte parâmetro:

ExtendedStatus On

Procure a string ExtendedStatus no arquivo e verifique se esta opção está comentada. Se sim, apenas descomente. Caso esteja com a opção Off, altere para On.

Em seguida, cole o trecho abaixo no final do mesmo arquivo:

<Location /server-status>
    SetHandler server-status
    Order deny,allow
    Deny from all
    Allow from 127.0.0.1
</Location>

Reinicie o serviço do Apache para que as configurações tenham efeito.

Bem simples de fazer o monitoramento do servidor Apache. Veja abaixo a tela de um gráfico com os itens disponíveis deste monitoramento.

Agora é só você adicionar as triggers de acordo com a sua necessidade e ficar tranquilo.

Até mais.

Usando LSOF para verificar porta usada por determinado processo

Outro dia fui realizar alguns testes em aplicações rodando no JBoss e verifiquei que nenhuma aplicação estava funcionando. Verifiquei no log do JBoss que o serviço iniciava e ocorria vários erros, informando que não conseguia fazer o deploy das aplicações.
Mesmo parando o serviço do JBoss, verifiquei com a ferramenta nmap que a porta 8080 continuava aberta.

# nmap -p 8080 localhost

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2012-11-12 14:09 BRST
Interesting ports on localhost.localdomain (127.0.0.1):
PORT     STATE SERVICE
8080/tcp open  http-proxy
Nmap finished: 1 IP address (1 host up) scanned in 0.012 seconds

Com o comando netstat verifiquei que realmente a porta estava na escuta por conexões.

# netstat -ntal | grep 8080
tcp        0      0 0.0.0.0:8080                0.0.0.0:*                   LISTEN

Com a ferramenta netstat não é possível ver qual o número do processo que está utilizando determinada porta. Então, para isso, precisamos usar uma outra ferramenta para descobrirmos qual processo está utilizando a conexão da porta 8080. LSOF (list open files) é a ferramenta para listar os arquivos abertos no sistema. Utilizando a opção -i tcp o sistema irá retornar apenas os arquivos abertos por conexões tcp.

# lsof -i tcp
redir     10909     root    3u  IPv4 442118       TCP *:webcache (LISTEN)

Dessa forma, se filtrarmos a saída do comando com o grep, não teremos o resultado esperado.

# lsof -i tcp | grep 8080

Isso porque o lsof por padrão faz a conversão das portas pelos serviços que as utilizam. Para desabilitar a conversão na execução do lsof, usamos a opção -P.

# lsof -i tcp -P | grep 8080
redir      12170     root  159u  IPv4 878525       TCP *:8080 (LISTEN)

A segunda coluna nos mostra qual o PID do processo em execução e que está utilizando a porta 8080. Com isso, podemos matar o processo e iniciarmos o serviço que deve utilizar a porta.

Se você não filtrar a saída do lsof, verá que as colunas exibidas por padrão do lsof são:

COMMAND     PID     USER   FD   TYPE DEVICE SIZE NODE NAME

Espero que está dica poupe muito tempo na busca por soluções a respeito de problemas de portas abertas por outros serviços que não seja o que você está acostumado a rodar. Isso acontece muito em ambientes administrados por muitas pessoas. O lsof é uma ferramente bastante poderosa e seu uso deve ser colocado em prática. Para mais detalhes: man lsof.

Escalonamento de I/O no GNU/Linux

Após dias de ausência, volto a postar no blog trazendo um assunto bastante interessante, ainda mais para os que gostam de performance.

O Kernel do GNU/Linux é responsável por controlar o acesso ao disco por meio de agendamento de requisições de I/O. Esse recurso é muito importante para sistemas que utilizam, de forma concorrente, o acesso à leitura e escrita em discos rígidos. Com isso, o sistema busca aperfeiçoar a utilização da cabeça de leitura/gravação dos discos de modo a economizar tempo e ter o melhor  desempenho possível para atender as requisições.

Existem diversos algoritmos que tem o propósito de organizar a leitura e escrita no disco. Os mais utilizados atualmente e que estão incluídos por padrão no Kernel 2.6 do GNU/Linux são: NOOP; CFQ; Anticipatory e Deadline.

Os objetivos de utilizar algoritmos de escalonamento de I/O são:

• Minimizar o tempo desperdiçado de procura no disco rígido.

• Priorizar certas solicitações de I/O pelos processos.

• Dar uma parte da largura de banda de disco para cada processo em execução.

• Garantir que certos pedidos serão atendidos antes de um prazo determinado.

 

Cada um destes algoritmos implementa níveis de recursos e características diferentes. É importante mencionar que cada algoritmo pode se adaptar melhor a determinadas cargas de trabalho e, por isso, devem ser realizados testes para escolher o que melhor se adapta. Para isso, recomendo a utilização de benchmarks como o Phoronix Test Suite.

Como mencionado anteriormente, a ideia de utilizar esses algoritmos é economizar o uso da cabeça de leitura e gravação do disco. Caso não existissem estes algoritmos, nenhum tipo de técnica seria adotado. Neste caso, as requisições seriam tratadas em uma estrutura de dados do tipo fila, como FIFO (First In First Out – O primeiro a entrar é o primeiro a sai). Nos dias de hoje, isso é inadmissível, pois os sistemas exigem rapidez e agilidade nos tratamentos de requisições, além da disponibilidade dos dados em um tempo hábil. Sem uma política de escalonamento, a cabeça de leitura/gravação iria perder muito tempo para atender as requisições. Observe o exemplo da figura abaixo:

Suponha que chegaram requisições para acesso ao disco na seguinte seqüência:

A > B > C. Conforme ilustrada na figura acima, a cabeça de leitura/gravação do disco será movida até o setor A, em seguida será movida para o setor B, e por último para o setor C.

Observe que é uma operação muito custosa: a cabeça de leitura iria passar pelo setor C em um segundo movimento para atender a requisição do setor B, desperdiçando tempo para finalizar o atendimento das três requisições.

Os algoritmos de escalonamento foram criados justamente para melhorar o

desempenho na utilização de dispositivos de armazenamento físico, de forma a atender diversas requisições de processos concorrentes em menos tempo. Ou seja, o algoritmo irá ordernar as requisições de maneira que todas possam ser atendidas no menor tempo possível. Vejamos então estes algoritmos:

NOOP

Técnica extremamente simples que praticamente não adiciona nenhum recurso. É um algoritmo com apenas uma fila, no mesmo estilo de FIFO, e utiliza uma quantidade mínima de CPU. O único recurso extra deste algoritmo é a execução de junção entre as últimas requisições apenas. Junção é o processo de agrupar setores idênticos a fim de ser realizada a operação uma única vez. Portanto, este mecanismo tenta melhorar os últimos itens da fila para buscar uma possibilidade de resumir operações de I/O.

CFQ

Complete Fair Queue. O principal conceito desde algoritmo é permitir que haja

justiça entre os processos do sistema ao utilizar recursos de I/O. Este algoritmo tenta distribuir a largura de banda de I/O entre todas as requisições. Através de um processo interno, este escalonamento procura criar filas independentes para cada processo que queira usar os recursos de I/O. CFQ é o algoritmo padrão na maioria das distribuições GNU/Linux, justamente por ser uma boa opção em sistemas onde o recurso de I/O não deve ser monopolizado por nenhum processo.

Anticipatory

Este algoritmo apresenta um atraso controlado para que algumas ações possam ser antecipadas. Isso é uma boa técnica para realizar operações de áreas de disco que estão próximas. Com as áreas adjacentes é possível realizar um processo de junção ou reordenação (controle devido dos movimentos de cabeça de leitura), melhorando o desempenho e a eficiência dos acessos ao disco. Um problema que pode ocorrer com o uso desde algoritmo é a presença de uma latência maior, causada pela espera das requisições.

Deadline

Este algoritmo oferece uma garantia de execução em tempo real das operações de I/O. Ele utiliza um conjunto de filas e estas são orientadas em tempos de execução. Esta política favorece as operações de leitura, pois tem um prazo de expiração menor se comparado com o prazo das operações de escrita.

Definindo um escalonador

O GNU/Linux oferece muitos recursos para personalização de sistemas. E pensando em oferecer mais praticidade, foi adicionado ao kernel 2.6 o recurso de não ser mais necessário reiniciar o  sistema para que as alterações de escalonador tornem-se efetivadas.

Portanto, o correto é testar cada escalonador em seu ambiente para obter os resultados e a partir daí analisar para se obter uma resposta com dados comprovados que a escolha seja a melhor possível.

Para verificar qual o escalonador que está ativo em seu sistema execute o comando conforme o exemplo abaixo:

[janssen@caixapreta ~]$ cat /sys/block/sda/queue/scheduler

noop anticipatory deadline [cfq]

O termo entre colchetes exibe qual o escalonador está ativado no sistema para o

dispositivo sda (o primeiro disco SATA instalado no sistema GNU/Linux). Para alterar o escalonador de I/O, é preciso executar o seguinte comando:

[janssen@caixapreta ~]$ echo deadline > /sys/block/sda/queue/scheduler

Essa configuração é efetivada em tempo real, não precisa reiniciar o sistema. Para efetivar a sua escolha, sugiro adicionar o comando acima em algum script de inicialização do sistema.

Aqui tem disponível o meu TCC sobre Otimização de Servidores GNU/Linux para SGBD. Nele tem um comparativo entre os escalonadores de I/O sobre alguns testes que eu fiz em alguns sistemas de arquivos utilizando disco SATA.

Para saber mais sobre o assunto, sugiro a leitura dos seguintes artigos:

Kernel Korner - I/O Schedulers
DevelopWorks

É isso leitores. Espero que aproveitem mais esta dica que eu selecionei para vocês.

Abraços e até a próxima.

Pós-graduação em Criptografia - UFF

Pessoal,

Recebi um e-mail da Coordenação do Curso de Especialização em Criptografia/UFF informando que as inscrições estão abertas para a turma 2012 do Curso de Especialização em Criptografia oferecido pelo Instituto de Matemática e Estatística da Universidade Federal Fluminense – IME/UFF.

Os objetivos do curso são: apresentar fundamentos teóricos e práticos da criptografia; oferecer base matemática para a compreensão dos sistemas criptográficos atuais, com ênfase nos de chave pública e fornecer uma introdução à segurança da informação e de redes.

O processo de inscrição se dará com o preenchimento pelo candidato do requerimento de inscrição, exclusivamente pela internet, no período de 13 de agosto de 2012 a 21 de setembro de 2012, no endereço http://www.labcas.uff.br/criptografia/inscricao.html e envio para a Coordenação do Curso, através de correio, via Sedex, com data limite de postagem no dia 21 de setembro de 2012, de documentação comprobatória de qualificação para a vaga.

Para maiores informações leia o edital disponível em http://www.labcas.uff.br/criptografia

É uma ótima oportunidade para quem quer se especializar em uma área específica. Desta vez não vou poder fazer o curso, pois estou cursando Administração em Redes Linux da UFLA e, como o curso é muito puxado, não vai dar para eu conciliar trabalho, vida familiar e duas pós ao mesmo tempo. Vou deixar para outra oportunidade.

Ah!. O curso de Criptografia é na modalidade EAD (ensino à distância), porém de uma instituição conceituada. Vale a pena.

Abraços.

Framework para benchmark - Phoronix Test Suite

Bom dia pessoal,

Ano passado, eu tive um projeto de migração de servidores middleware

para fazer e umas das tarefas para eu executar era verificar quais tecnologias utilizar, tais como sistemas de arquivos, arquitetura do kernel, escalonador de I/O, entre outras, para utilizar nos novos servidores.

Eu já tinha passado por uma experiência de verificar a performance entre sistemas de arquivos e escalonador de I/O para utilizar em partições para armazenamento de dados pelo SGBD PostgreSQL. Na época, eu usei os softwares iozone, bonnie++, BenchmarkSQL e Gnuplot para fazer os testes e comparar os resultados. Lembro que deu muito trabalho devido ao rígido processo de executar os testes com um ambiente nivelado para não ocorrer erros e desvios entre os testes.

Para este novo projeto, eu tive que pensar em uma maneira de executar os testes entre diferentes cenários sem perder tempo. Foi aí que, procurando na WEB, eu encontrei uma ferramenta que já faz tudo o que eu precisava, o PTS - Phoronix Test Suite. O PTS é um framework espetacular. Ele integra diversos benchmarks que executam testes de disco, memória, sistema, gráfico, rede e processador.

Vou explicar como é feita a instalação em ambiente GNU/Linux Debian, porém você pode instalar a ferramenta em sistemas Linux, OpenSolaris, *BSD, entre outros.


Instalação

Para instalar o PTS, é necessário a instalação das seguintes dependências:
- php5-cli
- php5-gd

Após baixar o arquivo phoronix-test-suite_4.0.0_all.deb , execute o seguinte comando:

# dpkg -i phoronix-test-suite_4.0.0_all.deb

Se após a execução do comando acima surgir mensagens de dependência de pacotes, execute o comando abaixo para resolver, baixar e instalar as dependências.

# apt-get -f install

Para outras distribuições e sistemas, acesse o site http://www.phoronix-test-suite.com/?k=downloads e faça o download.

Uma listagem das versões anteriores está disponível no endereço http://phoronix-test-suite.com/releases/


Executando o PTS

Após a instalação do PTS, basta executar o comando phoronix-test-suite interactive. Irá surgir um menu para você escolher qual opção deseja executar. Em um primeiro momento, você não precisa se preocupar, pois ao selecionar uma das opções de teste, automaticamente o sistema irá baixar os softwares necessários para executar os testes. A primeira execução de um teste ou suíte de testes pode demorar um pouco, pois é necessário baixar os softwares que realizam os testes e também suas dependências.

Se você desejar ver as principais opções para utilizar a ferramenta, basta executar o comando phoronix-test-suite.

Um exemplo de execução do PTS de forma não interativa é:

# phoronix-test-suite benchmark disk

Este benchmark executa uma conjunto de testes de disco e foi projetado para executar testes reais em discos e sistemas de arquivos.

Para saber quais as suítes de testes podem ser executadas pelo PTS, acesse o site do projeto OpenBenchmarking.

O que mais chama a atenção neste framework são os relatórios gerados. Estes relatórios são bem elaborados e fazer a comparação entres os testes realizados se torna uma tarefa fácil. Lembro até hoje do tempo que fiquei para plotar os resultados dos testes do iozone usando o Gnuplot. Fui bem trabalhoso (porém os gráficos do Gnuplot são altamente profissionais) .

Vou demonstrar aqui como executar um teste informando os dados para gravar o relatório.

 Execute:

# phoronix-test-suite benchmark memory

Aparecerá as seguintes perguntas:

- Would you like to save these test results (Y/n): Y
- Enter a name to save these results under: <nome_teste>
- Enter a unique name to describe this test run / configuration: <descricao_do_teste>
- New Description: (Aqui exibe a descrição do seu sistema, se não deseja alterar, pressione <enter>)

Neste momento, o teste iniciará. Quando o teste finalizar, será exibida a mensagem se deseja exibir os resultados no browser.

Do you want to view the results in your web browser (y/N): (se você não quiser ver os resultados no momento, poderá mais tarde acessar o resultado no seguinte diretório: ~/.phoronix-test-suite/test-results/<nome_teste>/composite.xml)

A próxima pergunta é: Would you like to upload the results to OpenBenchmarking.org (Y/n): (tecle Y se deseja enviar o resultado do teste para o site OpenBenchmarking.org)

Pronto. Agora é só analisar os resultados. Veja algumas imagens do resultado com o teste que eu fiz de memória.