utfpr – universidade tecnolÓgica federal do …cristina/thin_clients.pdf · instalando o pacote...
TRANSCRIPT
UTFPR – UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁCURSO DE TECNOLOGIA EM INFORMÁTICA
ANTONIO EMILIO W. AIEXARIANE GOMES DA SILVA DEZIDERÁ
MARIA CAROLINA KAMINSKI
THIN CLIENTSImplementação e análise de desempenho de terminais Thin Clients
nos computadores da Rede Local de Ensino
CURITIBA2006
ANTONIO EMILIO W. AIEXARIANE GOMES DA SILVA DEZIDERÁ
MARIA CAROLINA KAMINSKI
THIN CLIENTSImplementação e análise de desempenho de terminais Thin Clients
nos computadores da Rede Local de Ensino
Trabalho de conclusão do curso apresentada a Universidade Tecnológica Federal do Paraná, como requisito para obtenção do título de Tecnólogo em Informática.
Campo de conhecimento:Tecnologia da Informação
Orientadora: Profª Ana Cristina Kochem Vendramin
CURITIBA2006
2
ANTONIO EMILIO W. AIEXARIANE GOMES DA SILVA DEZIDERÁ
MARIA CAROLINA KAMINSKI
THIN CLIENTSImplementação e análise de desempenho de terminais Thin Clients
nos computadores da Rede Local de Ensino
Trabalho de conclusão do curso apresentada a Universidade Tecnológica Federal do Paraná, como requisito para obtenção do título de Tecnólogo em Informática.
Campo de conhecimento:Tecnologia da Informação
Data de aprovação:___/___/______
Banca examinadora:
_______________________________Prof. ª Ana Cristina Kochem Vendramin
_______________________________Prof. Christian Carlos Souza Mendes
_______________________________Prof. Robson Ribeiro Linhares
3
RESUMO
Este trabalho de graduação tem por objetivo o estudo e implementação de
estações “Thin Client”, arquitetura essa que consiste em um servidor central
realizando todo o processamento de clientes que usam terminais com pouco
hardware como interface ao usuário. A implementação foi feita em computadores da
Rede Local de Ensino (RLE) do Departamento Acadêmico de Informática (DAINF).
Através da utilização de softwares específicos para análise de rede e
pesquisas com as pessoas que usarão o sistema, foi possível gerar uma análise
detalhada de quão proveitosa e produtiva é a utilização deste sistema.
O resultado final deste projeto é disponibilizar computadores com uma
configuração mínima, utilizando-se de hardwares sem uso, por serem defasados, da
RLE, com processamento remoto em um servidor transparente aos usuários,
garantindo melhor desempenho.
Palavras-chaves:
Thin Clients, processamento remoto, performance.
4
LISTA DE FIGURAS
Figura 1 – ltspadmin 1/5............................................................................................ 20
Figura 2 – ltspadmin 2/5............................................................................................ 20
Figura 3 – ltspadmin 3/5............................................................................................ 21
Figura 4 – ltspadmin 4/5............................................................................................ 22
Figura 5 – ltspadmin 5/5............................................................................................ 22
Figura 6 – Login Tom’s Root Boot........................................................................... 24
Figura 7 – Tela de login no cliente.......................................................................... 26
Figura 8 – ltspcfg..................................................................................................... 27
Figura 9 – Arquivo dhcp.conf................................................................................... 29
Figura 10 – Arquivo hosts.allow.............................................................................. 32
Figura 11 – Arquivo exports.................................................................................... 33
Figura 12 – Arquivo lts.conf..................................................................................... 34
Figura 13 – Desempenho do servidor..................................................................... 40
Figura 14 – Consumo de largura de banda............................................................. 41
Figura 15 – Consumo geral do Gnome................................................................... 43
Figura 16 – Consumo de CPU do Gnome............................................................... 43
Figura 17 – Consumo de memória do Gnome........................................................ 44
Figura 18 – Consumo de carga do Gnome............................................................. 44
Figura 19 – Consumo de rede interna do Gnome................................................... 45
Figura 20 – Consumo geral do WindowMaker........................................................ 45
Figura 21 – Consumo de CPU do WindowMaker.................................................... 46
Figura 22 – Consumo de memória do WindowMaker............................................. 46
Figura 23 – Consumo de carga do WindowMaker.................................................. 47
Figura 24 – Consumo de rede interna do WindowMaker........................................ 47
Figura 25 – Ambiente gráfico, WindowMaker.......................................................... 48
5
LISTA DE TABELAS
Tabela 1 – Sites mais visitados............................................................................... 13
Tabela 2 – Softwares mais utilizados...................................................................... 14
Tabela 3 – Configuração Servidor e Clientes.......................................................... 17
Tabela 4 – Consumo máximo do servidor Gnome x WindowMaker........................42
6
LISTA DE ABREVIATURA E SIGLAS
DHCP Dynamic Host Configuration Protocol
EPROM Eraseable Programable Read-Only Memory
HD Hard Disk
KDE K Desktop Environment
LTSP Linux Terminal Server Project
NFS Network File System
PCI Peripheral Component interconnect
RLE Rede Local de Ensino
ROM Read-only Memory
TFTP Trivial File Transfer Protocol
UTFPR Universidade Tecnológica Federal do Paraná
XDMCP X Display Manager Control Protocol
7
SUMÁRIO
1. INTRODUÇÃO.................................................................................................... 10
2. THIN CLIENT...................................................................................................... 11
3. METODOLOGIA DE PESQUISA........................................................................ 13
3.1. Perfil dos usuários....................................................................................... 13
3.2. Aplicativos mais utilizados........................................................................... 14
4. RECURSOS EMPREGADOS............................................................................. 15
4.1. Sistema Operacional Linux......................................................................... 15
4.1.1. Distribuição Suse Linux...................................................................... 15
4.1.2. LTSP (Linux Terminal Server Project)................................................ 16
4.2. Hardware..................................................................................................... 16
5. IMPLEMENTAÇÃO............................................................................................. 18
5.1. Instalação do servidor................................................................................. 18
5.1.1. Instalando o pacote de utilitários LTSP.............................................. 18
5.1.2. Instalando os pacotes cliente do LTSP............................................... 19
5.2. Instalação dos clientes................................................................................ 22
5.2.1. Criando um Tom’s Root Boot.............................................................. 23
5.2.2. Gravando a imagem no HD................................................................ 24
5.2.2.1. Imagem para a placa de rede..................................................... 24
5.2.2.2. Comando Fdisk.......................................................................... 24
5.2.2.3. Sistema de arquivos................................................................... 25
5.2.2.4. Copiando arquivos LILO para o HD........................................... 25
5.2.2.5. Setor de boot.............................................................................. 26
5.3. Configurando os serviços do LTSP no servidor.......................................... 26
5.3.1. Runlevel.............................................................................................. 27
5.3.2. Interface Selection.............................................................................. 28
5.3.3. DHCP Configuration........................................................................... 28
5.3.4. TFTP Configuration............................................................................ 31
5.3.5. Portmapper Configuration................................................................... 31
5.3.6. NFS Configuration.............................................................................. 31
5.3.7. XDMCP Configuration......................................................................... 31
5.3.8. Create /etc/hosts entries..................................................................... 31
5.3.9. Create /etc/hosts.allow entries............................................................ 32
8
5.3.10. Create the /etc/exports file................................................................ 32
5.3.11. Create the lts.conf file....................................................................... 33
6. FUNCIONAMENTO DOS TERMINAIS THIN CLIENTS......................................35
7. ANÁLISE DE DESEMPENHO............................................................................ 38
7.1. Software Top............................................................................................... 38
7.2. Software Cacti............................................................................................. 39
7.3. Consumo de largura de banda.................................................................... 39
7.4. Uso de memória / CPU............................................................................... 41
7.4.1. Gnome................................................................................................ 42
7.4.2. WindowMaker..................................................................................... 45
7.5. Conclusão da análise de desempenho....................................................... 47
8. CONCLUSÃO..................................................................................................... 50
REFERÊNCIAS....................................................................................................... 51
ANEXO I.................................................................................................................. 52
9
1. INTRODUÇÃO
A Internet está se tornando cada vez mais indispensável, tanto nos meios
acadêmicos quanto nos meios profissionais, tornando as pessoas mais dependentes
de informações fornecidas por websites ou recebidas através de mensagens
eletrônicas, por exemplo.
A necessidade de acesso a informações em tempo real vem tornando as
pessoas mais dependentes dos computadores, que já não são mais suficientes para
todos que precisam dessa ferramenta. Com a evolução dos softwares e dos
hardwares, os computadores se tornam rapidamente obsoletos e por não atenderem
às necessidades do usuário de maneira satisfatória acabam sendo inutilizados. A
tecnologia Thin Client tem sido adotada visando suprir a necessidade de acesso à
rede a partir de uma estação de trabalho com custo reduzido.
A tecnologia Thin Client baseia-se no uso de computadores com recursos
mínimos de hardware, muitos deles até mesmo sem disco rígido, utilizando-os como
terminais leves que servirão de front-end, enquanto todo o processamento é
realizado em um servidor remoto. O servidor em questão deve possuir memória,
poder de processamento e capacidade de armazenamento adequados [FILHO 03].
O presente projeto consiste em implementar a tecnologia Thin Client na Rede
Local de Ensino (RLE) da Universidade Tecnológica Federal do Paraná (UTFPR)
através da utilização de um servidor com software adequado, permitindo a
ampliação de terminais de acesso aos usuários.
10
2. THIN CLIENT
A tecnologia Thin Client, como o próprio nome diz, baseia-se na idéia de um
terminal leve onde todo ou quase todo o processamento utilizado pelo cliente,
dependendo da forma com que é implementado, é realizado por um servidor.
Com o avanço da tecnologia, os sistemas Thin Client vêm se tornando cada
vez mais eficientes e viáveis em empresas, pois diminuem os custos de
implementação e manutenção. Em ambientes acadêmicos, principalmente em
Universidades Públicas, o Thin Client torna possível a reutilização de hardwares
legados, muito comuns em tal ambiente. A velocidade das redes atuais e a alta
capacidade de processamento que se pode alcançar em um terminal leve com
acesso a um servidor remoto tornam o uso desse sistema cada vez mais econômico.
Outra vantagem desta tecnologia, além do custo reduzido de implementação
que permite a reutilização de computadores sem uso, é a possibilidade de instalação
de softwares livres, com a eliminação de custos de aquisição de licenças de
softwares. Assim sendo, através desta tecnologia, um laboratório de informática
pode ser implementado com um custo reduzido.
Uma questão a ser considerada na sua utilização é a facilidade de
administração da rede, já que todos os aplicativos utilizados nos terminais leves
estarão sendo processados no servidor. Outro ponto a ser observado é que o
usuário não tem acesso às configurações do servidor, diminuindo o risco de
alteração do sistema. Além disso, como todos os aplicativos estão instalados e
configurados no servidor, todo e qualquer novo aplicativo que precisa ser
disponibilizado aos usuários, estará automaticamente disponível a todas as estações
após uma única instalação, diminuindo o tempo de instalação e manutenção do
ambiente.
A adoção da tecnologia permite a redução do tráfego na rede, já que o tráfego
gerado entre clientes e servidores é referente à modificação da imagem exibida nos
monitores e tráfego de entrada e saída dos periféricos, enquanto todos os dados a
serem processados permanecem armazenados no servidor.
Existem empresas no mercado que são especializadas nesta tecnologia. O
investimento necessário para se adquirir um sistema Thin Client customizado é mais
interessante quando comparado ao gasto necessário para a compra de estações de
trabalho.
11
O sistema faz uso de um servidor com capacidade de memória e
processamento adequados com terminais leves interconectados. Estas estações de
trabalho podem ser utilizadas sem discos rígidos ou com um disco rígido pequeno,
com capacidade apenas para carregar o sistema operacional padrão, ou podem
realizar o boot através da rede. Para isso, devem utilizar uma placa de rede
específica que contém um circuito EPROM (Eraseable Programable Read-Only
Memory) capaz de guardar instruções de boot. A opção do uso do disco rígido
pequeno foi a alternativa adotada neste projeto por ser mais viável, principalmente
devido aos equipamentos disponíveis na RLE.
12
3. METODOLOGIA DE PESQUISA
Na elaboração do presente projeto, um questionário foi desenvolvido [ver
ANEXO I] com o objetivo de verificar os softwares que deveriam ser disponibilizados
no servidor para utilização dos usuários da RLE, analisar o perfil destes usuários e o
verdadeiro motivo que os leva aos laboratórios na maioria das vezes, principalmente
fora do horário letivo.
Tal pesquisa foi realizada com aproximadamente 10% dos usuários que
utilizam os laboratórios (total de usuários: 1800), o que possibilitou uma visão geral
das necessidades do ambiente da RLE.
3.1. Perfil dos usuáriosAtravés dos dados recolhidos durante esta pesquisa pôde-se comprovar que
parte dos usuários utiliza o laboratório para fins não acadêmicos fora do horário de
aula (ainda que tais acessos sejam restritos), como exibido na Tabela 1.
Grande parte dos usuários perde tempo em busca de alguma alternativa para
burlar as restrições definidas pela administração da RLE, tais atos acarretam em
momentos onde os laboratórios se encontram superlotados, em sua grande parte
com usuários acessando conteúdos inadequados ou para fins pessoais,
impossibilitando o uso do mesmo para fins acadêmicos. A disponibilização dos
terminais leves para os usuários da RLE fora dos laboratórios tem como objetivo a
liberação dos laboratórios para fins extritamente acadêmicos.
Sites Visitados % de alunosWebmail 80%Conteúdo Acadêmico 50%Entretenimento 50%Notícias 39%Pessoais (blog, fotolog, orkut) 37%Tecnologia 30%
Tabela 1 – Sites mais visitados
3.2. Aplicativos mais utilizados
13
A entrevista também permitiu analisar os aplicativos mais utilizados pelos
usuários da rede (Tabela 2), podendo assim definir o que seria instalado, além dos
pacotes já definidos previamente para o correto funcionamento do servidor Thin
Client.
Softwares % de alunosOffice 80%Vizualizador PDF 50%Descompactador de arquivos 50%Plugins 39%
Tabela 2 – Softwares mais utilizados
Através deste resultado, foi definida a instalação dos seguintes pacotes
adicionais ao Sistema pré-definido pelo instalador do Suse como pacotes padrão
para um servidor:
• OpenOffice;
• Unzip;
• PDFViewer;
• Plugin do Macromedia Flash Player para os navegadores.
Foram mantidos pacotes que já vieram instalados e são importantes para a
utilização dos usuários, como por exemplo, o Mozilla Firefox e Real Player.
14
4. RECURSOS EMPREGADOS
O sistema operacional utilizado na implantação dos Thin Clients na RLE da
UTFPR é o Linux. O motivo para tal utilização é a padronização deste sistema na
RLE, onde todos os computadores utilizam a distribuição Suse Linux.
Na implantação dos Thin Clients, utilizou-se o LTSP (Linux Terminal Server
Project), que é um add-on ao servidor Linux. Este aplicativo, através dos serviços de
DHCP (Dynamic Host Configuration Protocol), TFTP (Trivial File Transfer Protocol),
NFS (Network File System) e XDMCP (X (window) Display Manager Control
Protocol), provê meios para que os terminais se conectem ao servidor de aplicações
e possam ser utilizados.
4.1. Sistema Operacional LinuxO Linux é um sistema operacional distribuído gratuitamente, criado em 1991
por Linus Torvalds na Universidade de Helsinky, na Finlândia [LINUS TORVALDS
06].
Por ser um sistema de código aberto, o GNU/Linux vem sendo desenvolvido
por milhares de pessoas no mundo que contribuem para o desenvolvimento do
kernel, ou de outras partes do sistema.
O kernel é o núcleo do sistema, a união de vários arquivos de código
implementados basicamente na linguagem C.
A distribuição Linux é uma versão do kernel, associada a aplicativos, com um
instalador, ferramentas de configuração, além de outros que o mantenedor achar
conveniente, de acordo com o objetivo da distribuição.
4.1.1. Distribuição Suse LinuxO Suse Linux é uma distribuição de origem alemã, que atualmente é mantida
pela Novell, empresa americana de informática. Sua principal vantagem é a fácil
utilização por pessoas sem familiaridade com o Linux, pois provê grande
compatibilidade com periféricos em geral, realiza configurações automáticas e conta
com interfaces amigáveis e intuitivas para o usuário comum, podendo ser chamada
de uma distribuição “Windows-like” [SUSE LINUX 06].
A instalação da distribuição Suse no servidor da RLE foi realizada de forma
padronizada, utilizando-se apenas os pacotes necessários para que o aplicativo no
15
servidor fosse executado de maneira otimizada. Os pacotes selecionados foram os
relacionados ao X, NFS, kernel do Linux, além dos aplicativos solicitados na
entrevista realizada com os usuários dos terminais leves, os alunos da UTFPR.
4.1.2. LTSP (Linux Terminal Server Project)O LTSP foi escolhido para ser usado nesse sistema por ser um dos softwares
mais comuns para implantação de terminais leves. O LTSP possui uma instalação
simplificada, permite uma configuração básica e proporciona resultados satisfatórios.
Além disso, a ampla documentação disponível ajuda na solução de problemas a
respeito da implementação dos terminais leves.
O LTSP atua como uma distribuição dentro de outra distribuição Linux,
contendo vários pacotes como bash (tradutor entre o usuário e o sistema
operacional, conhecido como shell), glibc (biblioteca que possui funções básicas
para o sistema operacional), fileutils (pacote de comandos compatíveis com Unix),
além de outros pacotes específicos do LTSP.
O LTSP provê uma solução simples e eficaz para utilização de terminais de
custo reduzido a partir de um servidor GNU/Linux, que pode ser configurado tanto
via ambiente gráfico quanto modo texto. No presente trabalho, os terminais de
acesso rápido à Internet, para usuários sem familiaridade com Linux, utilizam
ambiente gráfico.
A versão do LTSP utilizada foi a 4.1, disponível para download no site oficial
da ferramenta [LTSP 06] e distribuída sob a licença GPL (Gnu Public License).
A compreensão de como o LTSP funciona é essencial para uma rápida
solução de problemas, assim como manter documentações do processo é essencial
para facilitar manutenções futuras, por esse motivo o presente trabalho busca
documentar todo o processo de instalação de servidor e clientes, para que outros
possam vir a utilizá-lo se necessário.
4.2. HardwareA implementação deste projeto foi realizada reaproveitando hardwares
legados não utilizados na RLE, por não possuírem os requisitos mínimos para o
funcionamento do sistema em uso. Desta forma, foi possível obter oito
computadores para serem clientes e um servidor com configuração adequada para
suportar as necessidades destes clientes.
16
Para o melhor funcionamento das máquinas, buscou-se seguir um padrão na
configuração das mesmas, como mostrado na Tabela 3, apenas alterando o
tamanho do disco rígido das mesmas.
Configuração básica:- Sistema operacional LTSP;
- 64 MB de memória RAM;
- 1 placa de rede Realtek modelo rtl8139;
- Processador k6-2 500MHz.
Servidor- Sistema operacional Suse Linux;
- 1 HD de 40GB;
- 512 MB de memória RAM;
- 2 placas de rede Realtek;
- Processador Semprom 2400+.
Cliente 1- Configuração básica;
- 1 HD de 1.2GB.
Cliente 2- Configuração básica;
- 1 HD de 3.2GB.
Cliente 3- Configuração básica;
- 1 HD de 3.2GB.
Cliente 4- Configuração básica;
- 1 HD de 2.1GB.
Cliente 5- Configuração básica;
- 1 HD de 2.1GB.
Cliente 6- Configuração básica;
- 1 HD de 3.2GB.
Cliente 7- configuração básica;
- 1 HD de 540MB.
Cliente 8- Configuração básica;
- 1 HD de 6.1GB.Tabela 3 – Configuração Servidor e Clientes
17
5. IMPLEMENTAÇÃO
5.1. Instalação do ServidorPara a instalação do servidor, usamos apenas o que realmente seria
necessário, utilizando uma configuração básica do Suse Linux e adicionando os
pacotes referentes ao LTSP.
Para entender o funcionamento do LTSP, deve-se pensar nele como uma
mini-distribuição Linux, que é executado em qualquer sistema Unix, desde que este
possa dispor do serviço de NFS.
Existem três fases para a instalação do LTSP no servidor:
• Instalação dos pacotes de utilitários do LTSP (utilidades que nos fornecem
ajuda para o gerenciamento dos servidores e estações);
• Instalação dos pacotes clientes LTSP (pacotes necessários para o
funcionamento do processo);
• Configuração dos serviços necessários para o perfeito funcionamento do
processo.
5.1.1. Instalando o pacote de utilitários LTSP Desde a versão 4.1 (versão utilizada no presente projeto), o LTSP conta com
um pacote de utilitários para instalar e gerenciar os pacotes-cliente e para configurar
os serviços no servidor LTSP.
A ferramenta de administração se chama ltspadmin e a de configuração se
chama ltspcfg. As duas ferramentas são partes de um pacote chamado ltsp-utils que será instalado.
Para a instalação, primeiramente deve ser feito o download do arquivo
ltsp-utils corrente, hospedado na página oficial do LTSP [LTSP 06]. Após isto, o
arquivo deve ser descompactado e organizado em forma de diretórios corretamente.
O comando para que isso seja feito é o seguinte:
tar -zxvf ltsp-utils-0.11.tgz, onde:
• Z: descompacta o arquivo utilizando a ferramenta gzip;
• X: efetivamente extrai os arquivos, depois de descompactados;
• V: de verbose, opção para que os resultados sejam mostrados na tela;
• F: opção que vem antes do nome do arquivo a ser manipulado.
18
Após o comando, será criado o diretório ltsp_utils, com todo o conteúdo
do arquivo, devidamente descompactado e organizado. Para executar o script de
instalação os seguintes passos devem ser seguidos:
• Ir para o diretório onde o ltsp-utils foi descompactado;
cd ltsp_utils• Executar o script de instalação.
./install.shNessa linha de comando, o super-usuário (é bom lembrar que este comando
deve ser aplicado com o usuário root) faz a execução do script que se encontra no
diretório corrente. Este script irá executar os seguintes procedimentos:
• Copiar os arquivos ltspadmin e ltspcfg para o diretório de binários do
root (/usr/sbin), para que a partir daí, ele possa executar esses programas
estando em qualquer diretório;
• Após copiá-los, mudar suas permissões para 755 (leitura, escrita e execução
para o dono e leitura e execução para usuários do grupo e usuários comuns);
• Alterar o proprietário desses arquivos para o usuário root, bem como o grupo
a que eles pertencem, que passa a ser também o grupo root.
• O arquivo ltspinfo é copiado para o diretório de binários de usuários
comuns, para que quaisquer usuários possam acessá-lo.
Agora que os utilitários estão corretamente instalados, a administração dos
pacotes pode ser iniciada.
5.1.2. Instalando os pacotes cliente do LTSPPara a instalação dos pacotes referentes aos clientes, deve-se executar o
ltspadmin como super-usuário. Várias opções são disponibilizadas, dentre elas a
de Install/Update LTSP Packages, para baixar e instalar pacotes dos clientes
(vide Figura 1).
Como é a primeira vez que o LTSP está sendo utilizado no sistema,
aparecerá uma tela informando que o LTSP precisa ser configurado. O utilitário pede
para confirmar o endereço de onde os pacotes serão baixados (conforme pode ser
visto na Figura 2). O endereço default possui todos os pacotes e por ser oficial,
estará sempre disponível, se tornando o mais confiável. Basta pressionar enter para
confirmar. Após esta confirmação, será solicitado o diretório onde o LTSP deve ser
19
instalado. Por padrão, a opção é /opt/ltsp, e é exatamente esse diretório que
deve ser utilizado.
Figura 1 – ltspadmin 1/5
20
Figura 2 – ltspadmin 2/5
A seguir, é informado que se for necessário o uso de um proxy para
navegação no computador onde o LTSP está sendo instalado, deve ser digitado o
endereço do mesmo, caso contrário, basta digitar none. A mesma pergunta é feita
para um proxy FTP, bastando digitar seu endereço se necessário ou digitar none
(ver Figura 03). Finalmente, o script pede uma confirmação dos dados que
21
acabaram de ser configurados. Caso tudo esteja correto, basta digitar y, caso algo
tenha sido informado errado, digitar n e para correção de algum campo, digitar c.
Figura 3 – ltspadmin 3/5
22
A tela seguinte, requisita os pacotes a serem instalados (ver Figura 4). Existe
a possibilidade de escolher apenas alguns pacotes, ou deixar o LTSP bem completo.
Recomenda-se a instalação de todos eles, para que a variedade de possibilidades
nas estações de trabalho seja grande. Para selecionar os componentes basta
posicionar o cursor sobre eles e pressionar I, ou digitar A, caso queira selecionar
todos eles. Após fazer as escolhas necessárias, o usuário deve digitar Q, fazendo
com que os pacotes selecionados sejam instalados no sistema.
Mais uma tela de confirmação irá aparecer, bastando pressionar enter para
que os pacotes sejam efetivamente instalados (ver Figura 5). Após o término da
instalação, basta pressionar enter para voltar ao menu principal.
23
Figura 4 – ltspadmin 4/5
Figura 5 – ltspadmin 5/5
24
5.2. Instalação dos ClientesA opção pelo boot através de HDs (Hard Disk) com baixa capacidade de
armazenamento e que estavam sem uso na RLE foi feita devido a dois fatores.
Primeiro, o boot através de uma ROM (Read-Only Memory) presente na placa de
rede ficaria inviável, já que seriam adicionados custos de aquisição de circuitos ROM
e da gravação de uma imagem em cada circuito. Segundo, o boot através de
disquete traz riscos adicionais. Considerando que os computadores serão
disponibilizados ao público em geral, e que disquetes se corrompem facilmente, esta
situação poderia ocasionar a necessidade de manutenção constante, podendo levar
ao abandono do sistema.
Foram realizados testes para verificar os equipamentos que estavam em
condições adequadas de uso.
No projeto em questão, o HD armazena uma imagem de boot enquanto todo
o processamento é realizado pelo servidor.
Os itens necessários para a implantação do sistema foram:
• disquete formatado;
• disquete com o Tom's Root Boot (Distribuição Linux de tamanho mínimo
utilizada geralmente para manutenção da imagem contida no HD);
• placa de rede com conexão a LAN.
Nas seções subseqüentes encontra-se uma descrição detalhada do processo
de instalação nos computadores clientes.
5.2.1. Criando um Tom's Root Boot
Para criar uma imagem da distribuição Tom's Root Boot, é necessário acessar
o site oficial da ferramenta [TOM’S 06], clicar no link “TOMSRTBT” e selecionar a
versão mais atualizada.
Após esse passo escolhe-se o mirror (servidor) e inicia-se o download do
arquivo tomsrtbt-2.0.103.tar.gz (lembrando que como a versão pode ser
atualizada com o tempo, o nome do arquivo pode mudar, provavelmente começando
com tomsrtbt e terminando com .tar.gz).
25
Após o download, é necessário extrair o conteúdo desse arquivo e mudar o
diretório corrente para aquele criado após a extração.
O último passo é inserir um disquete formatado na unidade de disquete e
executar o shell script install.s, que está no diretório criado pela extração do
arquivo. O disquete com uma imagem do Tom's Root Boot será então criado.
5.2.2. Gravando a imagem no HD5.2.2.1. Imagem para a placa de rede
Como primeira etapa para o processo de gravação da imagem no HD, é
necessário fazer o download de uma imagem que ofereça suporte à placa de rede
do computador. No trabalho em questão, foram utilizados clientes com uma
configuração de hardware similar, o que impôs que todas as placas de rede fossem
iguais.
Os passos subseqüentes são:
• acessar o site onde estão disponíveis as imagens para as diversas placas de
rede existentes [ROM 06] e escolher a versão mais recente disponível;
• escolher o modelo da placa de rede em “Choose NIC/ROM type”;
• em “Choose ROM output format”, escolher “LILO/GRUB/SYSLINUX Loadable
Kernel Format (.zlilo)”, para que a imagem possa gerar um kernel carregável
quando a máquina inicializa;
• clicar em “Get ROM” para fazer download da imagem.
• Após o download, é necessário copiar a imagem para um disquete, e
posteriormente, para a estação de trabalho a ser utilizada.
5.2.2.2. Comando Fdisk
A segunda etapa do processo de gravação da imagem no HD é executar o
comando fdisk para apagar as possíveis partições existentes no HD em questão.
Para executar esta etapa é necessário:
• efetuar o boot no terminal leve com o disquete contendo a imagem do Tom's
Root Boot e efetuar o login com usuário root, seguindo as instruções da tela
mostrada (ver Figura 6);
26
Figura 6 – Login Tom’s Root Boot
• executar o fdisk:
fdisk /dev/hda (considerando que o HD seja reconhecido como hda,
como no presente trabalho, onde todos os HDs utilizados foram IDE e
configurados como master primários em cada estação de trabalho);
• apagar todas as partições presentes no HD utilizado e criar uma partição
Linux nova.
5.2.2.3. Sistema de arquivosA etapa subseqüente é a criação e a montagem de um sistema de arquivos.
Os procedimentos necessários para essa ação são:
• criar um sistema de arquivos na nova partição:
mke2fs /dev/hda1• criar um diretório /boot no RAMdisk que acabara de ser criado pelo Tom's
Root Boot:
mkdir /boot• montar o HD nesse diretório criado:
mount /dev/hda1 /boot• montar o Tom's Root Boot que está no disquete em /mnt:
mount /dev/fd0 /mnt
5.2.2.4. Copiando arquivos LILO para o HDNessa etapa os seguintes procedimentos são necessários:
• copiar o arquivo boot.b para o HD:
cp /mnt/boot.b /boot
27
• desmontar o disquete contendo a imagem do Tom's Root Boot:
umount /dev/fd0• trocar o disquete contendo a imagem do Tom's Root Boot e inserir o disquete
com a imagem que foi obtida no site [ROM 06].
• montar o disquete e listar os arquivos presentes nele:
mount /dev/fd0 /mntls /mnt
• copiar a imagem de boot para o HD (o nome do arquivo depende do modelo
da placa de rede selecionada):cp /mnt/NOME_DO_ARQUIVO_DE_IMAGEM /boot
5.2.2.5. Setor de boot
Nesta última etapa é necessário digitar o seguinte comando:echo image=/boot/NOME_DA_IMAGEM label=LTSP | /usr/bin/lilo
-C - -b /dev/hda1 -i /boot/boot.b -c -m /boot/mapApós a execução do comando será exibida uma mensagem do LILO
notificando que a instalação ocorreu com sucesso. A partir desse ponto é necessário
retirar o disquete da unidade e reiniciar o computador para que ele realize seu boot
remoto através da rede. Está, então, encerrado o processo de instalação.
Após este processo e a configuração do servidor, descrito na seção 5.3, os
terminais Thin Client estarão prontos para uso, a Figura 7 ilustra a tela de login de
usuário nos terminais.
28
Figura 7 – Tela de login no Cliente
5.3. Configurando os serviços do LTSP no servidorPara que o sistema possa funcionar de forma correta, o servidor deve
fornecer às estações de trabalho quatro serviços:
• DHCP;
• TFTP;
• NFS;
• XDMCP.
A configuração dos aplicativos acima citados é realizada através do utilitário
ltspcfg (Figura 8), que pode ser executado via interface de linha de comando, ou
através do próprio ltspadmin, selecionando a opção Configure LTSP.
Figura 8 – ltspcfg
Inicialmente, o ltspcfg verifica se os serviços necessários ao funcionamento
do LTSP estão presentes no servidor.
Após esta verificação, cada serviço deve ser individualmente configurado.
A tecla “enter” finaliza o aplicativo, e a tecla “C” permite configurar os
serviços.
29
A descrição sobre cada um dos serviços e a sua implementação no servidor
da RLE está disponível nas seções seguintes.
5.3.1. Runlevel
Em Unix, a variável runlevel é utilizada pelo programa init para determinar o
comportamento de um sistema em um determinado momento, por exemplo, quando
o mesmo é iniciado, reinicializado ou desligado.
No servidor LTSP, o runlevel é configurado como 5. Isto significa que o
servidor inicia em modo gráfico, com sua conexão à rede habilitada. Na maioria dos
sistemas, e no próprio Suse, o runlevel 5 já especifica a inicialização deste sistema
com os serviços NFS e XDMCP.
5.3.2. Interface Selection
Esta opção permite configurar a interface de rede que está conectada às
estações de trabalho, já que o servidor possui outra interface de rede para
conectividade com a Internet. A partir da seleção correta desta interface, a
ferramenta de configuração poderá criar os outros arquivos de configuração para o
servidor. No servidor em questão, a interface é a eth0.
5.3.3. DHCP Configuration
O DHCP, Dynamic Host Configuration Protocol, é um protocolo de serviço
TCP/IP que oferece configuração dinâmica de terminais, com concessão de
endereços IP de host e outros parâmetros de configuração para clientes de rede. O
DHCP usa um modelo cliente-servidor, no qual o servidor DHCP mantém o
gerenciamento centralizado dos endereços IP usados na rede.
Resumidamente, o DHCP opera da seguinte forma:
• Um cliente envia um pacote broadcast com um pedido de endereço;
• Os servidores DHCP que capturarem este pacote irão responder com um
pacote de configurações onde constará, pelo menos, um endereço IP, uma
máscara de rede e outros dados opcionais, como o gateway, servidores de
DNS, etc.
A ferramenta ltspcfg faz uma configuração básica do arquivo
/etc/dhcpd.conf. Esse arquivo define as regras sobre o funcionamento do
serviço DHCP que estará disponível no servidor. Após a criação desse arquivo, ele
30
deverá ser editado caso outras opções de configuração sejam necessárias. A cópia
do arquivo de configuração corrente no servidor (/etc/dhcpd.conf) está ilustrada
na Figura 9.
A primeira linha do arquivo de configuração especifica que a máscara de rede
criada é 255.255.255.0.
A segunda linha diz respeito ao endereço de broadcast da rede, como foi
utilizada a rede 10.0.0.0/24, seu endereço de broadcast será o 10.0.0.255/24.
A terceira linha informa aos clientes que se conectarem a este servidor a
localização do arquivo-imagem que deve ser copiado no momento do boot de cada
estação.
31
option subnet-mask 255.255.255.0;option broadcast-address 10.0.0.255;option root-path "10.0.0.254:/opt/ltsp/i386";option option-128 code 128 = string;option option-129 code 129 = text;option domain-name "ltsp";option domain-name-servers 10.0.0.254;option routers 10.0.0.254;
subnet 10.0.0.0 netmask 255.255.255.0 {range 10.0.0.1 10.0.0.254;default-lease-time 14400;max-lease-time 172800;
host ws001 {hardware ethernet 00:E0:7D:D0:76:72;fixed-address 10.0.0.1;filename "/tftpboot/lts/vmlinuz-2.4.26-ltsp-3"; }host ws002 {hardware ethernet 00:E0:7D:7E:F8:F7;fixed-address 10.0.0.2;filename "/tftpboot/lts/vmlinuz-2.4.26-ltsp-3"; }host ws003 {hardware ethernet 00:E0:7D:7E:F8:E5;fixed-address 10.0.0.3;filename "/tftpboot/lts/vmlinuz-2.4.26-ltsp-3"; }host ws004 {hardware ethernet 00:00:21:06:5B:9E;fixed-address 10.0.0.4;filename "/tftpboot/lts/vmlinuz-2.4.26-ltsp-3"; }host ws006 {hardware ethernet 00:E0:7D:D1:A8:63;fixed-address 10.0.0.6;filename "/tftpboot/lts/vmlinuz-2.4.26-ltsp-3"; }host ws007 {hardware ethernet 00:E0:7D:7F:10:3F;fixed-address 10.0.0.7;filename "/tftpboot/lts/vmlinuz-2.4.26-ltsp-3"; }host ws008 {hardware ethernet 00:E0:7D:7F:10:06;fixed-address 10.0.0.5;filename "/tftpboot/lts/vmlinuz-2.4.26-ltsp-3"; }}
Figura 9 – Arquivo dhcpd.confA quarta e a quinha linhas indicam como devem ser interpretadas as opções
option-128 e option-129, que nesta implementação não foram utilizadas.
A sexta linha define o nome de domínio para os clientes DHCP. Neste
trabalho, foi definido o nome “ltsp”.
32
A sétima linha define o endereço IP do computador que deve responder às
requisições de DNS (Domain Name System) dos terminais leves.
A oitava linha define o IP do gateway para os terminais leves, ou seja, define
o endereço do computador que fará o roteamento entre a rede dos terminais e a
Internet.
Após a configuração dessas opções, foi definido como as estações de
trabalho devem se comportar para que a rede funcione.
A linha subnet define a rede 10.0.0.0 com máscara 255.255.255.0
As opções que vêm a seguir definem os seguintes aspectos:
• range: quais endereços IP estão disponíveis para atribuição aos terminais
leves;
• default-lease-time: tempo em minutos que cada endereço ficará atrelado à
estação que o solicitou;
• max-lease-time: tempo máximo em minutos que cada endereço pode ficar
atrelado à estação que o solicitou.
O último passo é definir os IPs estáticos de cada terminal. O ambiente
utilizado no presente projeto, foi planejado e estruturado para ser de fácil acesso
para quaisquer pessoas que venham a administrar o sistema.
I. Na opção host, é definido o nome de cada terminal, e após a chave são
editadas as opções que dizem respeito somente àquela estação.
II. Na opção hardware definiu-se a placa de rede. No trabalho em questão a
opção escolhida foi Ethernet1 e em seguida o MAC Address2 da placa de
rede.
III. Na opção fixed-address informou-se o IP que o computador deve receber
quando enviar uma requisição DHCP. É importante salientar que o IP deve
estar dentro da faixa de IPs disponível para atribuição.
IV. Por último, a opção filename informa o caminho da imagem do kernel para
que cada estação possa fazer o download. Como os computadores utilizados
neste projeto foram padronizados, foi utilizada a mesma configuração para as
diferentes estações.
1 Tecnologia de interconexão para redes locais (Local Area Networks - LAN) - baseada no envio de pacotes. Define cabeamento e sinais elétricos para a camada física, e formato de pacotes e protocolos para a camada de controle de acesso ao meio (Media Access Control - MAC) do modelo OSI.2 Endereço físico da interface de rede, formado por 48 bits, representado em hexadecimal.
33
5.3.4. TFTP Configutation
Esta opção habilita o serviço TFTP no servidor, para que as estações de
trabalho possam fazer o download da imagem do kernel Linux que irão utilizar
durante todo o processo.
5.3.5. Portmapper Configuration
Habilita e configura as opções de portmapper, um servidor que converte
números de processos RPC em números nos protocolos TCP/IP ou UDP/IP,
utilizadas pelo LTSP para serviços como o NFS.
5.3.6. NFS Configuration
Esta opção configura o serviço NFS para iniciar após o boot do servidor.
Através do NFS, as estações de trabalho podem acessar diretórios localizados no
servidor que foram exportados (ver seção 5.3.10).
5.3.7. XDMCP Configuration
O protocolo XDMCP possibilita que a estação de trabalho receba uma tela de
login do servidor. Habilitando esta opção, o utilitário ltspcfg verifica quais
gerenciadores de display estão disponíveis e quais estão configurados para o uso.
No trabalho em questão foi utilizado o gdm, gerenciador de display do Gnome. Esta
opção também habilitou a requisição de janelas de display remotamente, sendo que
por padrão os gerenciadores não permitem tais requisições.
5.3.8. Create /etc/hosts entries
Os serviços de display (gdm) e NFS necessitam que os IPs das estações
sejam mapeados a seus respectivos hostnames. Para tal, o ltspcfg edita o arquivo
/etc/hosts e inclui em cada linha o IP da estação e seu respectivo hostname,
acompanhado do domínio.
5.3.9. Create /etc/hosts.allow entries
O LTSP adicionou informações ao arquivo hosts.allow (ver Figura 10) para
permitir que as estações cujos IPs são especificados tenham acesso aos serviços
indicados.
34
A sintaxe é “serviço: IP”
## LTSP-begin #### The lines between 'LTSP-begin' and 'LTSP-end' were added# on: Tue Jan 17 21:19:16 2006, by the ltspcfg configuration tool.# For more information, visit the LTSP homepage# at http://www.LTSP.org#
bootpd: 0.0.0.0in.tftpd: 10.0.0.253portmap: 10.0.0.253
## LTSP-end ##
Figura 10 – Arquivo hosts.allow
Através da Figura 10 pode-se verificar que foram definidor três serviços de
rede: bootpd, in.tftpd e portmap. O bootpd, que é a implementação do
DHCP/bootp, permite que os terminais obtenham um IP e possam fazer download
da imagem do sistema operacional. O in.tftp é apenas o nome do serviço de
TFTP (Trivial File Transfer Protocol), que fará a transmissão dos arquivos
necessários para o boot dos terminais. O portmap é essencial para o
funcionamento dos outros serviços de rede oferecidos pelo servidor.
5.3.10. Create the /etc/exports fileNo arquivo /etc/exports (Figura 11) são especificados quais diretórios têm
permissão para serem exportados remotamente através do NFS.
A sintaxe utilizada no arquivo é: “diretório IP/máscara (opções)”
No trabalho em questão utilizou-se a seguinte configuração:
## LTSP-begin #### The lines between 'LTSP-begin' and 'LTSP-end' were added# on: Tue Jan 17 21:19:54 2006, by the ltspcfg configuration tool.# For more information, visit the LTSP homepage# at http://www.LTSP.org#
/opt/ltsp 10.0.0.0/255.255.255.0(ro,no_root_squash,sync)/var/opt/ltsp/swapfiles 10.0.0.0/255.255.255.0(rw,no_root_squash,async)
## LTSP-end ##
35
Figura 11 – Arquivo exports
A opção 'ro' significa 'read-only', ou 'somente leitura'.
A opção 'rw' significa 'read-write' ou 'leitura e escrita'.
A opção 'no_root_squash' permite que o usuário root na estação tenha
acesso ao servidor com permissões de usuário root. Dessa forma as requisições de
root não são atendidas como usuário anônimo. Para implementações de terminais
leves esta opção deve estar habilitada.
A opção 'sync' não permite que o servidor envie respostas a requisições antes
que as alterações realizadas pela requisição atual sejam salvas em disco.
A opção 'async' permite que o servidor envie respostas a requisições antes
que as alterações realizadas pela requisição atual sejam salvas em disco.
5.3.11.Create the lts.conf file
O utilitário ltscfg cria o arquivo lts.conf que especifica as opções de
hardware para cada estação. O arquivo padrão criado pelo LTSP pode ser utilizado
com a maioria dos computadores que trabalham com barramento PCI (Peripheral
Component Interconnect). Nesta implementação, foram realizadas algumas
alterações neste arquivo relativas às configurações do mouse, do teclado e do
vídeo. A Figura 12 ilustra o arquivo de configuração.
O parâmetro SERVER especifica o IP do servidor LTSP.
A opção 'auto' no parâmetro XSERVER permite que o driver de vídeo seja
automaticamente verificado pelo servidor.
O parâmetro X_MODE_1 define a primeira resolução a ser utilizada pelas
configurações de vídeo da estação.
36
## Copyright (c) 2003 by James A. McQuillan (McQuillan Systems, LLC)## This software is licensed under the Gnu General Public License.# The full text of which can be found at http://www.LTSP.org/license.txt
## Config file for the Linux Terminal Server Project (www.ltsp.org)#
[Default] SERVER = 10.0.0.254
XSERVER = auto X_MODE_1 = 640x480 X_MOUSE_PROTOCOL = "Microsoft" X_MOUSE_DEVICE = "/dev/ttyS0" X_MOUSE_RESOLUTION = 400 X_MOUSE_BUTTONS = 2 X_MOUSE_BAUD = 1200 X_MOUSE_EMULATE3BTN = Y USE_XFS = N SCREEN_01 = startx
Figura 12 – Arquivo lts.conf
O parâmetro X_MOUSE_PROTOCOL especifica o protocolo a ser utilizado
pelo dispositivo mouse. No presente trabalho, foi utilizado o protocolo Microsoft.
O caminho da interface do mouse é definido em X_MOUSE_DEVICE.
O valor da 'resolução' do mouse é definido em X_MOUSE_RESOLUTION.
Para mouse serial, utilizou-se o valor 50 e para mouse PS/2, utilizou-se o valor 400.
O parâmetro X_BUTTONS especifica o número de botões do mouse.
O parâmetro X_MOUSE_EMULATE3BTN definido como Y (yes) permite
simular um terceiro botão no mouse, clicando-se simultaneamente nos botões direito
e esquerdo.
O parâmetro USE_XFS possibilita a utilização do X Font Server (recurso que
permite a leitura e utilização de fontes através do NFS), vindas de uma máquina
remota. Neste trabalho, essa opção foi desabilitada por não ser necessária ao
funcionamento dos terminais.
Por último, o parâmetro SCREEN_01 definido como “startx”, informa à
estação de trabalho que o script /etc/screen.d/startx deve ser executado,
permitindo que a estação funcione utilizando um ambiente gráfico.
37
6. FUNCIONAMENTO DOS TERMINAIS THIN CLIENTS
Este capítulo contém a descrição passo-a-passo do funcionamento de um dos
terminais Thin Clients desde o boot via LTSP. Serão descritas também algumas
configurações que podem vir a ser necessárias para o pleno funcionamento dos
terminais, e seus respectivos arquivos e scripts.
1. A imagem do kernel do Linux é carregada na memória do terminal leve. Isso
pode ocorrer de várias maneiras: através de uma interface de rede
(BootROM), disquete, HD, CD-ROM ou até mesmo um dispositivo USB.
Como explicado anteriormente, optou-se pelo boot através da rede, com as
informações contidas em HD, similar a uma BootROM que solicita todos os
dados via interface de rede. Logo depois de ser carregada na memória, a
imagem do kernel começa a ser executada.
2. O kernel inicializa e tenta reconhecer os periféricos.
3. Durante o carregamento da imagem do kernel na memória, uma outra
imagem, ramdisk, também é carregada em memória. O parâmetro
root=/dev/ram0, informa ao kernel que esta imagem deve ser montada
como o diretório raiz.
4. Normalmente, quando o processo de boot do kernel encerra, o kernel executa
o programa init. Nesta implementação, o LTSP foi configurada para executar
um pequeno shell script passando o parâmetro init=/linuxrc à linha de
comando do kernel.
5. O script /linuxrc inicia procurando por um dispositivo de rede nos barramentos
PCI da placa-mãe em questão. Para cada dispositivo PCI encontrado,
verifica-se no arquivo /etc/niclist se há uma combinação de hardware-módulo.
Quando uma combinação é reconhecida, o módulo que oferece suporte a
esse dispositivo de rede é retornado e o mesmo é carregado no kernel. Para
dispositivos ISA (Industry Standard Architecture), o módulo deve ser
especificado explicitamente assim como a IRQ (Interrupt Request) e outros
parâmetros de endereços.
6. Um pequeno cliente DHCP chamado dhclient é executado, enviando uma
requisição DHCP ao servidor. Ao receber uma resposta do servidor, o
38
dhcpclient executa o script /etc/dhclient-script que configura a
interface de rede de acordo com as informações recebidas.
7. Até o momento, o sistema de arquivos está montado na memória RAM da
estação de trabalho. O próximo passo é montar um sistema de arquivos via
NFS. O diretório exportado pelo servidor é o /opt/ltsp/i386. O script
/linuxrc monta esse diretório em /mnt para depois realizar um pivot_root,
que é a troca do sistema de arquivos atual (memória RAM) pelo novo (NFS).
Quando essa etapa encerrar, o novo sistema de arquivos NFS estará
montado no diretório /, e o velho em /oldroot. Após essa etapa, o script
/linuxrc não é mais utilizado.
8. O programa /sbin/init é executado. Este programa lê o arquivo
/etc/inittab e configura o ambiente da estação de trabalho.
9. Um dos primeiros itens no inittab é o comando rc.sysinit que executa o script
rc.sysinit enquanto o computador estiver no modo sysinit. O script rc.sysinit,
cria um ramdisk de 1 MB na memória. O ramdisk é montado no diretório /tmp
. Quaisquer arquivos que precisem ser salvos irão existir no diretório /tmp,
com links simbólicos apontando para esses arquivos.
10. O sistema de arquivos /proc é montado.
11. É realizado um “parsing”3 no arquivo de configuração lts.conf. Todos os
parâmetros contidos nesse arquivo da estação de trabalho em questão são
configurados como variáveis de ambiente que são lidas pelo script rc.sysinit.
12. A interface de rede loopback é configurada. Ela tem como IP padrão o
endereço 127.0.0.1.
13. Se a opção LocalApps, dentro do arquivo ltsp.conf, estiver habilitada, o
diretório /home é montado para que as aplicações possam acessar os
diretórios dos usuários.
14.Vários diretórios são criados para armazenar arquivos transientes que são
necessários enquanto o sistema estiver em execução. Os seguintes diretórios
são criados:• /tmp/compiled;• /tmp/var;• /tmp/var/run;
3 Processo pelo qual o programa “quebra” as informações de um arquivo linha por linha para que os parâmetros e opções definidas neste arquivo sejam devidamente carregados.
39
• /tmp/var/log;• /tmp/var/lock;• /tmp/var/lock/subsys.15. O arquivo /tmp/syslog.conf é criado contendo informações sobre o
daemon syslogd a respeito do endereço de host para qual ele deve enviar os
syslogs (logs do sistema). Essa informação é configurada no arquivo lts.conf
(ver seção 5.3.11). Logo após esse passo, o daemon syslogd é colocado em
execução.
16. O script /sbin/init assume o controle novamente, e muda o runlevel para
o nível 5. Essa mudança carrega no sistema todas as configurações que
constam no arquivo /etc/inittab.
17. Por padrão, existem parâmetros no inittab que executam o script
/etc/screen_session em tty1, tty2 e tty3, ou seja, têm-se três sessões
simultaneamente. Essa opção pode ser alterada no arquivo de configuração
lts.conf.
18. No arquivo lts.conf, existe um parâmetro XSERVER. Se ele não estiver
presente, ou configurado como “auto”, é realizada uma verificação automática
da placa de vídeo.
19. O arquivo XF86Config é criado com base nos parâmetros contidos em
/etc/lts.conf. Após sua criação, o script startx executa o X Window
System utilizando este arquivo de configuração.
20. O servidor X envia uma requisição XDMCP ao servidor LTSP, que lhe
responde com uma caixa de diálogo para login. A partir desse momento os
usuários podem efetuar login e utilizar a estação de trabalho.
40
7. ANÁLISE DE DESEMPENHO
Com o objetivo de verificar e confirmar a funcionalidade dos terminais Thin
Clients da maneira como foram implementados e baseados na configuração do
servidor apresentada na Tabela 3, utilizou-se o software Cacti [CACTI 06] para gerar
gráficos e analisar alguns aspectos importantes para a boa performance dos
terminais. Além dos gráficos gerados pelo Cacti, utilizou-se também a ferramenta
top, software do Linux que mostra o desempenho do servidor, processos iniciados,
tempo de uso da CPU, utilização da memória RAM e Swap [TOP 94].
Foram feitos testes de desempenho nos terminais utilizando os ambientes
gráficos Gnome e WindowMaker por serem dois exemplos de ambientes gráficos
bastante utilizados, porém com uma grande diferença de desempenho, como será
provado nas seções seguintes. Para testes de desempenho do servidor (CPU,
memória) foi utilizado o pacote de aplicativos OpenOffice e para analisar o
desempenho da rede, foi utilizado o Mozilla Firefox como aplicativo básico para
navegação e download de arquivos.
Apesar do ambiente gráfico utilizado na RLE atualmente ser o KDE (K
Desktop Environment), foi escolhido para testes no presente projeto o Gnome, pois
seu comportamento diante da abertura de várias janelas e de múltiplos acessos é
comprovadamente melhor em relação ao KDE, como pode ser visto no benchmark4
feito por Carsten Haitzler [HAITZLER 05].
7.1. Software TopO software Top provê uma leitura dinâmica, em tempo real de um sistema em
funcionamento. Ele pode exibir informações resumidas do sistema, bem como uma
lista de tarefas que estão sendo gerenciadas pelo kernel do Linux. As informações
mostradas e os tipos, ordem e tamanho das informações dos processos são todos
configuráveis de acordo com a intenção do usuário.
O software original foi escrito por Roger Binns, baseado no software PS
(Report Process Status), de Branko Lankester. Atualmente, o software vem sendo
atualizado por James C. Warner, responsável pela versão utilizada no presente
projeto.4 Processo sistemático e contínuo de avaliação dos produtos, serviços e processos de trabalho, com a finalidade de introduzir melhorias na organização. Os resultados deste processo proporcionam às empresas comparar os seus produtos, serviços e métodos de trabalho.
41
7.2. Software CactiO Cacti é uma solução completa para gerar gráficos do uso da rede e do
processamento do computador, possuindo dezenas de opções para personalizar os
gráficos, o que possibilitou uma adaptação melhor às informações que foram
necessárias coletar. Com a sua utilização, podem-se guardar os gráficos que mais
interessavam, possibilitando uma análise futura dos dados, bem como uma
comparação entre determinados testes.
O software é desenvolvido em PHP (Hypertext Preprocessor) e sua
configuração é bastante simples. Abaixo, os requisitos básicos para que o Cacti seja
executado no servidor:
• Servidor Web, neste caso a implementação foi feita com o Apache;
• PHP, com versão superior a 4.0, além dos pacotes de extensão php-snmp e
php-gd2;
• Banco de dados MySql;
• SNMP (Simple Network Management Protocol), protocolo padrão usado para
gestão de redes;
• rrdtool, (Round Robin Database), sistema para armazenar e mostrar dados
obtidos em série [RRDTOOL 06].
Como a instalação do Cacti foi feita para auxiliar a realizar as análises de
desempenho, e sua implementação é dispensável numa futura configuração de
terminais leves em outros ambientes, informações completas sobre instalação e
configuração não serão adicionadas no presente projeto. Maiores informações sobre
implementação do Cacti podem ser obtidas no Portal PoP-PR [CACTI 04].
7.3. Consumo de largura de bandaPara analisar o desempenho da rede comprovando que a largura de banda
disponível é suficiente, além da navegação em sites, foram feitos downloads de
arquivos da Internet e após o início de cada download, foram extraídas as
informações pelos softwares Top e Cacti.
Um após o outro, os terminais foram ligados iniciando o download de arquivos
diversos, mantendo a navegação. O terminal seguinte só era iniciado depois que o
download do terminal em uso já tivesse sido iniciado.
42
A partir das informações extraídas do software Top (ver Figura 13), pode-se
concluir que a navegação, mesmo que simultaneamente em todos os terminais
leves, impactará muito pouco no desempenho do servidor. Consumindo em média
no máximo 46,9% da CPU, 508 MB de memória RAM, 226 MB de swap e atingindo
uma carga de trabalho de 3,27 (cálculo da média do número de processos na fila de
execução e os em execução em períodos de 1, 5 e 15 minutos), conclui-se que,
apenas para navegação, o servidor disponível encontra-se com uma configuração
adequada.
CONSUMO BASE DO SERVIDORtop - 10:14:53 up 5 min, 4 users, load average: 0.64, 1.25, 0.68Tasks: 94 total, 1 running, 93 sleeping, 0 stopped, 0 zombieCpu(s): 6.3% us, 1.0% sy, 0.0% ni, 92.7% id, 0.0% wa, 0.0% hi, 0.0% siMem: 515376k total, 328976k used, 186400k free, 16252k buffersSwap: 1052216k total, 0k used, 1052216k free, 180380k cached
CONSUMO 8 TERMINAIS NAVEGAÇÃO / DOWNLOADtop - 10:44:54 up 35 min, 4 users, load average: 3.27, 3.31, 2.36Tasks: 291 total, 1 running, 290 sleeping, 0 stopped, 0 zombieCpu(s): 46.9% us, 17.2% sy, 0.0% ni, 3.6% id, 27.4% wa, 2.6% hi, 2.3% siMem: 515376k total, 508808k used, 6568k free, 5200k buffersSwap: 1052216k total, 226520k used, 825696k free, 121532k cached
Figura 13 – Desempenho do servidor
Analisando o tráfego na rede a partir dos dados extraídos do software Cacti
(ver Figura 14), pode-se notar que a largura de banda disponível para os terminais
não será um empecilho para o seu bom funcionamento, já que o projeto dispõe de
um hub 10/100Mbps, concluindo que o gargalo serão os servidores externos à
UTFPR.
No gráfico, a interface eth0 simboliza a comunicação entre terminais e
servidor e a eth1 simboliza a comunicação do servidor com a rede externa.
43
Figura 14 – Consumo de largura de banda
7.4. Uso de memória / CPUPara fazer a análise do comportamento do servidor com os terminais
funcionando com aplicações que demandam um consumo maior de memória e CPU,
o procedimento foi semelhante ao teste de rede: um após o outro os terminais foram
ligados e foi iniciado um aplicativo qualquer do pacote OpenOffice. Depois de todos
44
os terminais estarem em funcionamento e com o aplicativo em execução, foi iniciado
o uso do navegador Mozilla Firefox, para simular o ambiente ao qual os usuários
terão acesso.
Através dos dados coletados pelo top e pelo Cacti verificou-se que a memória
RAM disponível no servidor deste projeto (512MB) suporta o funcionamento de 8
terminais com aplicações em uso e navegação na Internet, porém em determinados
momentos poderá ocasionar uma lentidão, pois a quantidade de processos
hospedados no servidor demandam um consumo muito grande de memória. Esta
lentidão é amenizada quando o ambiente gráfico utilizado é o WindowMaker, como
mostra a Tabela 4.
Gnome WindowMakerCPU 57,39% 37,83%Memória RAM 509.504 KB 507.108 KBSwap 338.916 KB 44.500 KBLoad 3,20 2,27
Tabela 4 – Consumo máximo do servidor Gnome x WindowMaker
O consumo da CPU também é amenizado utilizando o ambiente gráfico
WindowMaker, porém este consumo não se mostrou como um possível problema
para o funcionamento dos terminais.
Levando em consideração os resultados das análises realizadas, determinou-
se que os terminais leves disponibilizados aos usuários da RLE seguiriam uma
configuração básica utilizando-se do ambiente gráfico WindowMaker, porém fica
claro que por ser um ambiente gráfico minimalista, a adaptação dos usuários
ocorrerá aos poucos e deverá ser acompanhada pelos responsáveis pelo
funcionamento dos Thin Clients.
Os dados mais detalhados com relação aos testes com Gnome e
WindowMaker são apresentados nas seções seguintes.
7.4.1. GnomeNesta seção são apresentados os gráficos gerados pelo software Top
relacionados ao consumo do servidor Thin Client e do tráfego de rede utilizando o
ambiente gráfico Gnome.
45
Simulou-se o ambiente gradual de utilização dos terminais Thin Clients por
usuários finais, com o uso de aplicações do pacote OpenOffice e navegação com o
Mozilla Firefox.
Através da Figura 15 pode-se perceber que o consumo de memória durante a
utilização do ambiente gráfico Gnome é alto e o consumo de CPU é médio, podendo
impactar no funcionamento indevido dos terminais leves em determinados
momentos, atingindo uma média de 509 MB de memória RAM, 338 MB de swap e
55,4% de uso de CPU.
CONSUMO BASE GNOMEtop - 11:17:14 up 14 min, 3 users, load average: 0.10, 0.22, 0.31Tasks: 96 total, 1 running, 95 sleeping, 0 stopped, 0 zombieCpu(s): 7.0% us, 0.7% sy, 0.0% ni, 90.7% id, 1.7% wa, 0.0% hi, 0.0% siMem: 515376k total, 290240k used, 225136k free, 16324k buffersSwap: 1052216k total, 0k used, 1052216k free, 148208k cached
CONSUMO 8 TERMINAIS APLICAÇÃO / NAVEGAÇÃOtop - 11:59:17 up 56 min, 10 users, load average: 1.76, 1.08, 0.92Tasks: 272 total, 3 running, 269 sleeping, 0 stopped, 0 Cpu(s): 55.4% us, 3.3% sy, 0.0% ni, 32.4% id, 9.7% wa, 1.3% hi, 0.9% siMem: 515376k total, 509504k used, 5872k free, 6240k buffersSwap: 1052216k total, 338916k used, 713300k free, 198528k cached
Figura 15 – Consumo geral do Gnome
A partir da Figura 16 pode-se verificar que o maior consumo de CPU do
servidor utilizando-se do ambiente gráfico Gnome é devido aos processos
hospedados pelos usuários dos terminais leves, ocupando na maior parte do tempo,
mais da metade do processamento total do servidor, atingindo um máximo de
37,79%.
46
Figura 16 – Consumo de CPU do Gnome
A memória do servidor Thin Client durante a utilização do ambiente gráfico
Gnome é sem dúvida o recurso mais explorado pelos terminais leves, como pode
ser comprovado na Figura 17.
Figura 17 – Consumo de memória do Gnome
A carga de trabalho apresentada pelo servidor Thin Client no momento em
que se utilizou o ambiente gráfico Gnome foi superior a apresentada quando foi
utilizado o WindowMaker (Figura 23), comprovado na Figura 18.
47
Figura 18 – Consumo de carga do Gnome
O tráfego da rede interna utilizada pelos terminais para o processamento das
requisições dos usuários é significante, porém não se torna um problema,
considerando os equipamentos e configurações utilizadas no presente projeto (ver
Figura 19).
Figura 19 – Consumo de rede interna do Gnome
7.4.2. WindowMaker
Nesta seção são apresentados os gráficos de consumo do servidor Thin
Client e do tráfego de rede utilizando o ambiente gráfico WindowMaker.
Simulou-se o ambiente gradual de utilização dos terminais Thin Clients por
usuários finais, com o uso de aplicações do pacote OpenOffice e navegação com o
Mozilla Firefox.
48
Através da Figura 20, pode-se perceber que o consumo de memória
utilizando-se do ambiente gráfico WindowMaker é alto, mas não tão alto quanto o
consumo do ambiente gráfico Gnome, e o consumo de CPU é médio, podendo
causar um impacto menor no funcionamento dos terminais leves em determinados
momentos. Esta utilização atingiu uma média de 50 MB de memória RAM, 44 MB de
swap e 37,9% de uso de CPU.
CONSUMO BASE WINDOWMAKER top - 12:19:49 up 12 min, 3 users, load average: 0.07, 0.27, 0.31Tasks: 92 total, 1 running, 91 sleeping, 0 stopped, 0 zombieCpu(s): 9.0% us, 1.7% sy, 0.0% ni, 83.4% id, 0.7% wa, 0.3% hi, 0.0% siMem: 515376k total, 318688k used, 196688k free, 16716k buffersSwap: 1052216k total, 0k used, 1052216k free, 179408k cached
CONSUMO 8 TERMINAIS APLICAÇÃO / NAVEGAÇÃOtop - 12:55:32 up 48 min, 14 users, load average: 1.27, 0.95, 0.68Tasks: 165 total, 1 running, 164 sleeping, 0 stopped, 0 zombieCpu(s): 37.9% us, 2.8% sy, 0.0% ni, 57.1% id, 3.1% wa, 1.3% hi, 0.8% siMem: 515376k total, 507108k used, 8268k free, 3028k buffersSwap: 1052216k total, 44500k used, 1007716k free, 137052k cached
Figura 20 – Consumo geral WindowMakerA partir da Figura 21 pode-se verificar que o maior consumo de CPU do
servidor durante a utilização do ambiente gráfico WindowMaker é devido aos
processos hospedados pelos usuários dos terminais, ocupando na maior parte do
tempo, mais da metade do processamento total da máquina, atingindo um máximo
de 32,05%.
Figura 21 – Consumo de CPU do WindowMaker
49
A memória do servidor Thin Client com o ambiente gráfico WindowMaker é
sem dúvida o recurso mais explorado pelos terminais leves, como pode ser
comprovado na Figura 22.
Figura 22 – Consumo de memória do WindowMaker
A carga de trabalho apresentada pelo servidor Thin Client utilizando-se o
ambiente gráfico WindowMaker, é ilustrada na Figura 23.
Figura 23 – Consumo de carga do WindowMaker
O tráfego da rede interna utilizada pelos terminais para o processamento das
requisições dos usuários é significante, porém não se torna um problema,
considerando os equipamentos e configurações utilizados no presente projeto (ver
Figura 24).
50
Figura 24 – Consumo da rede interna do WindowMaker
7.5. Conclusão da Análise de DesempenhoAtravés dos resultados obtidos durante os testes, pode-se concluir que a
performance apresentada pelo servidor e, consequentemente, pelos terminais leves,
é garantidamente melhor quando é utilizado o ambiente gráfico WindowMaker. O
possível gargalo que surgirá em determinados momentos é relativo ao consumo de
memória, pois as aplicações como, por exemplo, o OpenOfficce, quando executadas
nos terminais, consomem um nível muito alto de memória.
É notável que o Gnome trata-se de um ambiente gráfico mais intuitivo e
agradável aos usuários, porém para a finalidade apresentada e requerida pelos
terminais leves na UTFPR, o impacto será mínimo. Além disso, os responsáveis pela
administração da rede deverão estar disponíveis por um determinado tempo para
auxiliar os usuários que não se sentirem aptos a utilizar o sistema. Portanto, o
ambiente gráfico disponível nos terminais para os usuários é o WindowMaker como
pode ser visto na Figura 25.
51
Figura 25 – Ambiente gráfico, WindowMaker
52
8. CONCLUSÃO
O presente trabalho consistiu da implementação da tecnologia Thin Client na
Rede Local de Ensino (RLE) da Universidade Tecnológica Federal do Paraná
(UTFPR), utilizando um servidor e oito terminais leves, que se encontram à
disposição do Departamento Acadêmico de Informática (DAINF) para utilização por
usuários da instituição.
A utilização de computadores para atividades pessoais vem causando
transtornos em todas as instituições e o custo de novas aquisições é alto, fazendo
com que surjam novas alternativas para atender a essa demanda.
Os objetivos do trabalho foram atingidos, através da disponibilização do
sistema Thin Client utilizando os equipamentos que estavam em desuso na
instituição, implementados com sistema operacional Linux, e em uma rede em que
os alunos não têm acesso a modificações de configurações dos equipamentos. O
sistema mostrou-se uma opção viável, devido ao seu reduzido custo de
implementação, associado a uma menor demanda de manutenção da rede. Outro
aspecto a ser considerado é que o sistema demonstrou ser uma importante forma de
permitir a ampliação de acesso à rede fora dos horários de atividade curricular,
liberando os equipamentos durante os horários de aulas para as atividades
didáticas.
Na análise dos ambientes gráficos utilizados, o WindowMaker apresentou o
melhor desempenho, devido a maior simplicidade de sua implementação, sendo que
o Gnome demonstrou ser o de maior complexidade, gerando inclusive possíveis
gargalos na memória RAM disponível.
Os aplicativos escolhidos para testes de utilização nos Thin Clients foram o
Open Office e o Mozilla Firefox, que na análise demonstraram resultados regulares
devido a capacidade da memória RAM disponível no servidor Thin Client, contudo
sem impedir a adequada utilização dos terminais.
Quanto à rede construída com os equipamentos legados, a análise
demonstrou um desempenho satisfatório, com capacidade de transferência de 100
Mbps. O processamento disponível no servidor atendeu a demanda dos oito
terminais leves acoplados, atendendo as expectativas dos usuários.
53
Portanto, conclui-se que a implementação dos Thin Clients na RLE foi
satisfatória, trazendo uma funcionalidade nova para hardwares em desuso e uma
nova opção para os usuários da UTFPR.
54
REFERÊNCIAS
[CACTI 04] RRDTool e Cacti. Disponível em: <http://www.pop-pr.rnp.br/tiki-index.php?page=Medidas%20de%20trafego%20RRDTOOL%20e%20CACTI> Acesso em: 11 de agosto de 2006.
[CACTI 06]. Site oficial Cacti. Disponível em: <http://www.cacti.net/> Acesso em: 11 de agosto de 2006.
[FILHO 03], FILHO, Joanilo de Souza. Análise Comparativa entre ambientes computacionais baseados nas tecnologias de processamento distribuído e de Thin Client. Blumenau, novembro de 2003. Disponível em: <http://www.inf.furb.br/~pericas/orientacoes/ThinClient2003.pdf> Acesso em: 28 de junho de 2006
[LINUS TORVALDS 06] Linus Torvalds. Disponível em: <http://pt.wikipedia.org/wiki/Linus_Torvalds> Acesso em 20 de março de 2006.
[LTSP 06], Site oficial LTSP. Disponível em: <http://www.ltsp.org> Acesso em: 10 de março de 2006.
[ROM 06] Imagens para placas de rede diversas. Disponível em: <www.rom-o-matic.net> Acesso em: 15 de março de 2006.
[HAITZLER 05] Home Page Carsten Haitzler. Disponível em: <http://www.rasterman.com/index.php?page=News> Acesso em: 20 de agosto de 2006.
[RRDTOOL 06]. Site oficial RRDTool. Disponível em: <http://www.rrdtool.org/> Acesso em: 11 de agosto de 2006.
[SUSE LINUX 06]. Site oficial Suse Linux. Disponível em: <http://www.novell.com/products/suselinux/> Acesso em: 20 de março de 2006
[TOM’S 06], Site oficial Tom’s Root Boot. Disponível em: <http://www.toms.net/rb> Acesso em: 15 de março de 2006.
[TOP 94] Unix On-line Man pages. Disponível em: <http://unixhelp.ed.ac.uk/CGI/man-cgi> Acesso em: 20 de agosto de 2006.
55
ANEXO I
PESQUISA REFERENTE À UTILIZAÇÃODOS LABORATÓRIOS DA UTFPR
1– Nome: ______________________________________________________
2– Idade: _____
3- Sexo: [] Feminino [] Masculino
4- Código: _________
5- Curso:[] Ensino Médio
[] Engenharia Industrial Elétrica[] Engenharia Industrial Mecânica
[] Tecnologia em Artes Gráficas[] Tecnologia em Construção Civil[] Tecnologia em Eletrônica[] Tecnologia em Eletrotécnica[] Tecnologia em Informática[] Tecnologia em Mecânica[] Tecnologia em Móveis[] Tecnologia em Química Ambiental[] Tecnologia em Radiologia
[] Especialização em Tecnologia Java
Outros: _________________________________________
6- Em que tipos de site costuma navegar na Internet:[] Webmail[] Notícias[] Páginas pessoais (blogs, fotologs, orkut)[] Diversão[] Tecnologia[] Conteúdos AcadêmicosOutros: _________________________________________
7- De quais softwares você mais depende quando utiliza a Internet, além do navegador?[] Visualizador de documentos, planilhas, entre outros[] Descompactador de arquivos[] Visualizador PDF[] PluginsOutros: _________________________________________
8- Com que freqüência utiliza os laboratórios da UTFPR?[] Apenas durante as aulas[] 1 ou 2 vezes por semana[] 1 ou 2 vezes por semana, além dos dias de aula[] Todos os dias[] Não utilizo o laboratório
Assinatura: _____________________________________
56