I. Monitoração de Filas de Execução de Processos
- implementado entre servidores Digital e IBM comunicando com um computador Linux
- comunicação feita por sockets com programas em C
- criação automatizada da página HTML por um script PERL
Este projeto consistia em disponibilizar em uma página web o status das filas de jobs em dois servidores do
CCE: uma IBM SP2 (mesma família do Deep Blue) de doze processadores e uma Digital AlphaServer 4100 de
quatro processadores. O status era obtido executando um shell script em cada uma das máquinas, para cada
um dos processadores, e guardando os dados em um arquivo. Os comandos a serem executados eram
diferentes em cada máquinas: llq na IBM e bqueues na Digital. A comunicação entre os servidores e o
computador Linux era feito por sockets já que este era o mais confiável no caso. Os arquivos eram
transferidos e salvos no Linux, e posteriormente eram processados por um script Perl, executado por um
daemon.
No sistema Linux foi necessário usar um daemon que cuidava para que uma conexão fosse aberta quando viessem
pedidos dos servidores. Houve problemas com a estabilidade do nosso daemon, mas isso foi resolvido usando um
utilitário do qmail chamado svscan. Esse programa tratava de checar periodicamente se o daemon estava rodando,
e, no caso de queda, tratava de executá-lo de novo.
Nos servidores que estavam sendo monitorados foram feitas modificações no crontab para que o programa de
comunicação fosse rodado a cada cinco minutos. Esse programa primeiro estabelecia a conexão, a seguir ele se
identificava e depois mandava os dados.
Resultado final: IBM
II. Modificação de script em servidor de mail
- script usado em servidor da Sun responsável pelo sistema de mail Spider da USPnet
- script sh interfaceando um script PERL
O sistema de mail usado pelos usuários da USPnet roda em um servidor SUN com Solaris.
Havia a necessidade de adicionar um sistema de quota nesse sistema para os usuários que acessavam por
shell e usavam algum leitor similar ao pine. Este programa deveria levar em conta o espaço ocupado pelo
home do usuário e o espaco ocupado no spool pelo mail (não apagado) para decidir se a quota havia sido
estourada e tomar as providência cabiveis, desde dar simples avisos até suspender a conta do usuário
automaticamente. Era necessário também modificar a parte do script responsável pela criação dos usuários
para levar em conta esse novo detalhe. Foi usado como base o script que era utilizado na época e entre as
alterações que foram feitas constavam a criação de módulos em PERL para fazer o processamento
necessário e a alteração do próprio script
para fazer as devidas chamadas.
III. Monitoração de servidores por rede
- monitoração de vários tipos de servidores a partir de um sistema Linux
- objetivo final: administração remota integrada à Internet
O objetivo desse projeto é de construir um sistema que alerte um operador de que uma dada máquina está
com algum problema, desde um problema de rede, falta de espaço em disco até um crash que o tenha tirado
do ar. Alguns desses comandos são executados no sistema que está sendo monitorado e outros a partir de um
sistema central. O esquema utilizado é similar ao do projeto das filas. A comunicação é feita por sockets
entre o sistema sendo monitorado e o sistema Linux central, que gera relatórios automaticamente a cada cinco
minutos com os dados de cada sistema atualizado.
Primeiro foi feita uma busca para ver se havia alguma ferramenta já existente que atendesse as nossas necessidades.
Infelizmente todas elas tinha algum tipo de desvantagem; algumas não monitoravam muitos dos aspectos
que eram importantes para nos, outros não eram adaptáveis para os diferentes tipos de sistemas que tínhamos
no CCE. Por isso foi necessário fazer uma implementação quase do zero, aproveitando apenas a parte de sockets.
A primeira parte desse projeto já foi concluido. Na segunda parte e idéia era implementar um sistema de senhas
e terminais remotos seguros que permitiria ao administrador logar no sistema e fazer quaisquer alterações necessárias
sem ter que ter acesso ao console da máquina. Essa fase do projeto não foi feita ainda e há dúvidas se algum dia
será implementado, já que há outros projetos mais
urgentes a serem feitos.
IV. Análise do código do sistema de Webmail da USP
- código original em Perl com pequenas porções de shell script
- análise do código para determinar se é possível algum ganho de performance
- portar o sistema de servidores Sun para servidores Alpha
O sistema de Webmail da USP estava necessitando de um upgrade devido ao fato de que os atuais quatro
servidores Sun não estavam conseguindo atender a demanda dos usuários. Esses quatro servidores estavam
operando com um sistema de load-balancing que roteava os pedidos que chegavam para a máquina que
estivesse menos carregada no momento. Para substitui-los foram trazidos dois servidores Alpha da Compaq
que funcionariam como um cluster.
O nosso desafio era analisar o código do sistema, identificar eventuais gargalos, e fazer o possível para tornar-lo
mais eficiente. A maior parte do código estava em Perl, fragmentada em diversos arquivos, com a comunicação
entre si feita por pipes. Ele tinha sofrido várias alterações, e a pouca documentação que havia não era de muita
ajuda. Outro detalhe que complicou mais ainda nossa tarefa foi o fato dos autores do sistema já terem deixado
a empresa. Concluímos que por hora era melhor deixarmos o código com o menor número de alterações possível,
para primeiro concentrarmos na portagem do sistema para os Alpha.
Tambem seria necessário fazer várias alterações devido a diferenças entre os dois sistemas operacionais. Um
exemplo é o subsistema de autenticação de usuários. Enquanto o Solaris usa shadow passwords, esse recurso
não existe nos sistemas Tru64. Atualmente estamos cuidando dessa
fase do projeto.
V. Migração do sistema POP da USP
- roda atualmente em um sistema Linux Slackware
- implementação de um virtual server usando ipchains, ipvs e piranha rodando sobre um sistema Red Hat
- roteamento dos pedidos para dois servidores Slackware
Tal como o sistema Webmail, tornou-se necessário fazer um upgrade também no sistema POP de mail. O computador
que rodava o servidor POP morreu devido a um crash de disco e por isso foi necessário configurar um outro
computador as pressas para servir de substituto. Também foi decidido que o novo sistema POP rodaria em dois
computadores com um terceiro gerenciando os pedidos de acordo com o nível de carga em cada um (load-balancing).
No sistema que gerenciaria os pedidos foi instalado Red Hat. Foram usados o ipchains, da versão 2.2 do kernel, e o ipvs,
um patch para a versão 2.2.16, para rotear os pacotes. O processo todo foi supervisionado através do piranha.
Nos dois sistemas Slackware que fariam o processamento dos pedidos em si foram aplicados patches no kernel
para possibilitar o uso com o ipvs e foi instalado o TCP Wrappers, por
questões de segurança.
VI. Instalação e configuração de um sistema IBM AIX
Como parte do treinamento foi dado aos estagiários a tarefa de instalar um sistema operacional AIX em um
servidor IBM RISCserver 6000. Apesar de ser um sistema já meio antigo, com um processador fraco para os
padrões atuais, ele tem uma excellente capacidade de fazer IO, já que ele é totalmente baseado em SCSI.
Observamos alguns detalhes interessantes sobre o AIX durante a instalação. O seu sistema de particionamento
de disco por exemplo parece ser extremamente avançado. As partições podem ser inicializadas com o menor tamanho
necessário para a instalação, podendo ser aumentadas de tamanho posteriormente de acordo com a necessidade,
tudo isso com o sistema online. Há também a possibilidade de dividir uma única partição entre vários discos, algo
que provavelmente também será possível brevemente no Linux. Outro utilitário útil no AIX é o smit, que ajuda
a administrar o sistema. Ele tem uma interface gráfica muito intuitiva e poderosa, e parece ser muito melhor do
que qualquer equivamente no Linux ou no Windows.