Paper pxe 23 03 20004
10
Click here to load reader
Transcript of Paper pxe 23 03 20004
Utilização de Computadores Pessoais optimizados para Terminais
Gráficos no Hospital São Sebastião
Nuno Lucas – [email protected]
Rui Gomes – [email protected]
Hospital São Sebastião, S.A – Rua Dr. Cândido Pinho, 4520 Santa Maria da Feira,
http://www.hospitalfeira.min-saude.pt, Tel: 256 379 700 Fax: 256 378 867
Abstract
Cada vez mais se tem verificado que nas empresas a utilização de plataformas de
sistemas operativos com acessos centralizados têm revertido substancialmente em
beneficios operacionais, melhorias na gestão e redução de custos. Assim tal como os
thin clients já são tidos como as plataformas por excelência dos interfaces de muitos
utilizadores de plataformas Windows ou UNIX, também o Hospital São Sebastião
adoptou uma solução do tipo. Neste contexto, este paper pretende mostrar, de uma
forma detalhada como a equipa operacional encontrou uma alternativa prática e
económica de reaproveitamento de todo o seu stock informático, à partida absoleto, para
ter postos de trabalho actualizados e fiáveis a serem utilizados pelos seus profissionais
de saúde. Palavras chave como boot remoto, Linux, PXE, CITRIX, Windows, entre
outras são as constantes do arrojado projecto que permitiu de uma forma generalizada
melhorar as velocidades de acesso às aplicações cliente/servidor e aplicações web
based, minimizar as intervenções tidas nas falhas de hardware, tornar os sistemas
operativos mais estáveis, garantir melhor protecção anti-vírus, reduzir substancialmente
o tempo necessário para a instalação ou reconfiguração de todo um sistema cliente e
obter melhorias consideradas relativas à gestão do parque informático.
Introdução
Tendo como objectivos a diminuição de
custos, a reutilização de equipamento
informático obsoleto (evitando assim
elevados investimentos em novos
equipamentos) e acima de tudo a
necessidade premente de fiabilidade e
simplicidade na gestão de um número
cada vez maior de postos de trabalho,
foi projectada e instalada uma solução
baseada em Terminal Services e no
conceito “Thin Client”1.
Para o efeito, foram estudadas algumas
soluções sempre tomando em
consideração que o novo ambiente do
utilizador deveria manter a estrutura
Windows por uma questão de
operacionalidades e para evitar algum
impacto na mudança para o utilizador
final. Ao nível do sistema operativo
1 Também conhecidos por “fit client”
para os equipamentos clientes foi
testada uma instalação reduzida de uma
distribuição de Linux (no caso a
distribuição Red-Hat 9) no disco local
do cliente, e uma outra que efectuava o
boot2 remoto baseado também em
Linux. A distribuição Red-Hat 9,
mesmo reduzida era muito pesada para
atingir os objectivos e levantava alguns
problemas na parametrização quando se
pretendia disponibilizar um ambiente
windows3. Também este processo
obrigava ao investimento de um grande
conjunto de configurações em cada um
dos postos de trabalho.
2 Arranque do sistema operativo
3 Este acesso é suposto ser feito através de um
ICA Client. “Independent Computing
Architecture” – aplicativo para Linux - neste
caso - que viabiliza a connexão com servidor
CITRIX.
Foi testada então outra alternativa
conhecida como remote-boot ou
network boot. Este mecanismo consiste
na implementação do boot via placa de
rede. A ideia subjacente ao network
boot é a de um computador desprovido
de recursos locais, nomeadamente
discos rígidos, poder “arrancar”
utilizando recursos remotos e
centralizados. Também aqui optamos
pela utilização do Linux, mas desta vez,
apenas se usou o kernel (2.4) compilado
apenas com os módulos necessários à
detecção do hardware dos clientes.
Utiliza-se um cliente ICA para Linux, o
que produziu uma imagem (initrd4 +
kerne5l) com cerca de 5Mb,
contrapondo os 400 a 500Mb
necessários numa outra instalação. Foi
também necessário incluir o X
(XFree86 4.3) de forma a poder
suportar o ICA.
O Projecto
O projecto inicial consistiu em
disponibilizar através do Metaframe
FR36 um ambiente de trabalho
produtivo e capaz de responder às
exigências que as aplicações utilizadas
no Hospital faziam sentir à algum
tempo, especialmente as aplicações de
imagem radiológica e prescrição
médica. Pretendia-se também dar início
a uma reforma do parque informático
mais antigo, visto já não terem
condições de por si só dar resposta às
necessidades. A centralização da
informação dos utilizadores e de uma
grande parte dos processos, era também
um objectivo antigo do Hospital,
aumentando assim as vantagens de todo
o sistema. Aliado a isto existia a
necessidade de fiabilidade, uma vez que
a manutenção e reparação de avarias
consome grande parte do tempo dos
recursos humanos do serviço de
informática. Foi proposto a utilização de
4 Initial Ram Drive
5 Núcleo do sistema operativo
6 http://www.citrix.com
um equipamento chamado WyseWeb7,
de dimensões bastante reduzidas, que
substituía um computador. Mas,
colocava-se a questão - O que fazer com
o equipamento existente e o
investimento efectuado?
Implantação do remote-boot
O Departamento de Informática do
Hospital São Sebastião, S.A. tinha já
adquirido algum know-how sobre o
conceito de thin client uma vez que, á
cerca de seis meses atrás foram
implementados terminais gráficos Sun
Ray 100 da Sun Microsystems em
alguns serviços do Hospital. Assim o
Departamento de Informática do
Hospital deu início, em meados de
Fevereiro de 2004, às pesquisas sobre
remote-boot. A princípio foram sentidas
algumas dificuldades devido á
inexperiência no ambiente Linux, á
adaptação do sistema ás necessidades
reais do Hospital, á configuração do
serviço de DHCP8, e em particular, á
compilação de imagens. Superadas as
dificuldades, o remote-boot trouxe
inúmeras vantagens quer a nível de
gestão quer a nível da manutenção dos
equipamentos. O remote-boot é um
processo dividido em três fases:
1- Reconhecimento da informação sobre
as configurações do cliente.
2- Download de um ficheiro que vai ser
o responsável pelo controlo do boot
durante um período de tempo.
3 - Execução desse
mesmo ficheiro para o
controlo temporário do
boot passando depois o
controlo novamente para
o BIOS do computador de forma a não
comprometer o arranque de todo o
sistema.
O Funcionamento do remote-boot
7 http://www.wyseweb.com
8 Dynamic Host Configuration Protocol
Durante o arranque (inicialização) de
um posto de trabalho, antes do arranque
do sistema operativo (boot), são
executados vários programas de
inicialização residentes em ROM que
fazem parte do BIOS do computador.
Esta fase do arranque é designada de
“pré-boot”. Aproveitando esta
característica é possível colocar uma
ROM no computador de tal modo que
este em lugar de efectuar o boot de
forma tradicional (através de
dispositivos locais), utilize serviços de
rede para o efeito. Para isso algumas
placas de rede possuem um socket livre
para a colocação de uma EPROM9 e
permitem definir o endereço de
memória onde essa ROM será
“colocada”. As ROM´s de boot
destinam-se a obter de um servidor de
rede o sistema operativo para o boot,
contendo para isso, o driver apropriado
para a placa de rede, software de rede
(TCP/IP/UDP/IPX…) e um cliente de
rede para receber os ficheiros (TFTP10
,
NFS, …). Uma ROM de boot não pode
9 Erasable Progamable ROM
10 Trivial File Transfer Protocol
simplesmente iniciar o boot quando é
executada pelo BIOS. Devem inicializar
os dispositivos e devolver o controlo ao
BIOS, sob pena de comprometer todo o
processo. O primeiro ficheiro recebido
da rede é conhecido por Network
Bootstrap Program (NBP11
) que é
executado e assume o controlo das
operações.
Bootp/DHCP + TFTP
Embora existam algumas soluções
proprietárias, a mais usada é a que
utiliza os protocolos Bootp/DHCP e
TFTP (tendo sido usado o DHCP no
hospital). O seu funcionamento é
composto por algumas etapas como se
pode ver na figura seguinte.
1. O “software” residente na
EPROM emite um pedido de
DHCP em broadcast.
2. O servidor de DHCP responde
enviando a informação
necessária, entre ela o nome do
ficheiro de boot e o endereço IP
do respectivo servidor TFTP.
3. O cliente emite um novo pedido
mas desta vez de TFTP com o
objectivo de obter o ficheiro de
boot.
4. O ficheiro de boot é executado,
podendo apresentar várias
características (difere de sistema
para sistema).
5. O ficheiro de boot emite um
pedido TFTP para o servidor
onde reside a imagem.
6. O servidor de TFTP envia a
imagem pedida e o cliente
coloca-a no local adequado.
7. Finalmente é desencadeado o
boot.
O que é o PXE?
Em 1998, um grupo de fabricantes
formou um consórcio designado
11
Na realidade o NBP é um interpretador de
comandos
Processo de remote-boot
WfM12
. Foi liderado pela Intel e
composto pela 3Com, HP, Dell,
Compaq, etc. Este consórcio formou
um standard, da indústria! O PXE13
é uma parte da especificação WfM
que tem como objectivo a redução
de custos e a simplificação da gestão
dos computadores pessoais. O PXE
funciona numa placa de rede
(NIC14
) instalada no computador e
torna essa placa de rede um
dispositivo de arranque (boot
device). O objectivo desta
especificação é tornar a placa de
rede um boot device standard, tal
como os discos rígidos, as disquetes,
etc. O PXE faz “boot” dos clientes
pela rede transferindo um ficheiro
que é uma imagem de boot a partir
de um determinado servidor. Essa
imagem pode ser um sistema
operativo (Linux, Unix, Windows,
etc.), ou um “Pré-OS15
”. O PXE não
é específico para um determinado
sistema operativo, pode carregar
qualquer um através da rede. O PXE
está disponível em EPROM´S que
podem ser adicionadas às placas de
rede (neste momento existe um
grande número de placas que já
suportam PXE) e permitir assim que
estas suportem a especificação PXE.
Actualmente a versão PXE
disponível é a 2.1.
Vantagens do remote-boot
O network boot não é um conceito
tão recente como possa parecer.
Existem inclusive alguns métodos,
entre os quais o da Novell e da IBM
que vêm sendo disponibilizandos
desde os anos 80. Nessa altura as
12
Wired for Management 13
Preboot Execution Environment 14
Network Interface Card 15
Processo de carregar um sistema operativo
pequeno pré-compilado para executar
determinada função.
redes eram o grande obstáculo. De
qualquer forma, actualmente o PXE
constitui um standard o que permite
que fabricantes quer de hardware
quer de software possam suportar e
desenvolver esta arquitectura.
Existem muitas vantagens em
utilizar este “método” de boot:
1. Todos os computadores fazem
boot da mesma maneira o que
permite um controlo mais
apertado pelo administrador.
2. A actualização do software é
feita remotamente sem que um
técnico tenha de se deslocar
fisicamente ao local.
3. Os backups dos documentos de
todos os utilizadores podem ser
centralizados mais facilmente.
4. Os clientes não são infectados
por vírus (no caso da instalação
ser apenas em memória).
5. O investimento em hardware é
drasticamente reduzido e em
alguns caso completamente
anulado.
Estas são algumas das vantagens, mas
certamente existem muitas outras que
poderão ser muito mais interessantes e
vantajosas, dependendo apenas do
ponto de vista de cada um.
Administração Zero
A utilização deste tipo de métodos de
arranque, é muito vantajosa para
administradores de parques
informáticos com elevado número de
postos de trabalho. Como os ficheiros
do sistema operativo são obtidos a partir
de servidor, todos os postos arrancam
de igual modo (como foi referido
anteriormente) e sob o controlo directo
do administrador. A actualização de
todo o software, inclusive do sistema
operativo, é realizada num único posto e
colocada no servidor para
posteriormente ser replicada para todo o
parque. Uma vez que se trata de um
ambiente “pre-boot”, sem retirar a
EPROM, é impossível aos utilizadores
efectuar boot de uma forma diferente e
sem o controlo do administrador. Mas,
muito embora se trate sem dúvida de
uma solução de Administração Zero,
existem, como seria de esperar, alguns
inconvenientes. O principal problema é
a existência de um parque informático
muito variado, o que obriga à criação de
várias imagens, geralmente uma por
cada tipo de computador, o que levanta
problemas de gestão das mesmas. Um
outro problema é o facto de alguns
sistemas operativos não suportarem (ou
serem muito pouco eficientes)
configurações dinâmicas, como por
exemplo a atribuição de um nome ou
um IP ao cliente. Embora estes
problemas possam ser resolvidos,
acrescentam bastante complexidade a
todo o sistema. Com a configuração
dinâmica pretende evitar-se que tenha
de se manter no servidor uma imagem
por cada posto de trabalho, o que não
faria sentido. Uma solução aceitável
será manter no servidor uma imagem
por cada tipo de computador, embora o
ideal seria ter apenas uma única imagem
para todos os postos.
Selecção da Imagem
O facto de existirem várias imagens
poderá levantar algumas dúvidas de
como é que o cliente “sabe” que
imagem carregar! A resposta a isso é o
MAC Address, o IP, o nome ou até
mesmo um grupo. Para tentar
simplificar, segue-se um exemplo
prático do que na realidade acontece
(por exemplo com o IP).
Exemplo: No ficheiro de configuração
do DHCP (no Hospital é utilizado
DHCP static devido à facilidade de
gestão das impressoras) é atribuído um
IP ao MAC Address de uma
determinada placa de rede. No momento
de seleccionar a imagem correcta cada
cliente vai procurar um ficheiro cujo
nome seja o seu endereço IP
(previamente atribuído) no formato
hexadecimal. Caso não encontre esse
ficheiro, vai procurar um outro sem o
algarismo mais à direita, caso não
encontre retira outro algarismo a direita
e assim sucessivamente até que fique
apenas um e se mesmo esse não for
encontrado, vai carregar um ficheiro
(que tem de existir) designado de
default. Podemos ver um exemplo
concreto; ao MAC Address
00:04:75:FF:76:84 é atribuído pelo
servidor de DHCP o IP 192.168.5.22,
que convertendo cada um dos quatro
números que compõem o IP
separadamente, ficamos com C0A8516.
Neste caso, o primeiro ficheiro a ser
procurado será o ficheiro C0A8516.
C0A8516 - 1 host
C0A851 - 10 host´s
C0A85 - 254 host´s
C0A8 - 64516 hosts´s
C0A - ---
C0 - ---
C - ---
Default - Todos os hosts´s da rede
No Hospital, cada um destes ficheiros
contêm informação sobre o kernel a
carregar pelo cliente, quais os
parâmetros a passar ao kernel (caso seja
necessário) e qual a initrd que deve ser
carregada. Após esta selecção, o cliente
dá inicio ao download do kernel e da
initrd, a qual é descompactada e
colocada em memória. Este processo de
selecção da imagem a carregar abre a
possibilidade de poder definir grupos
uma vez que pode-se dizer que todos os
computadores com o IP 192.168.5.xxx
(C0A85) vão fazer download da
imagem A e que os computadores com
o IP 192.168.11.xxx (C0A8B), fazem o
download da imagem B. Este processo
pode ser refinado até ao ponto de definir
um ficheiro para cada cliente, mas como
foi referido anteriormente, o ideal seria
ter apenas uma única imagem e nesse
caso seria apenas preciso utilizar o
ficheiro default para todos os clientes.
Como será fácil de depreender, o
ficheiro default será o mais genérico
possível, depois vai especificando à
medida que o nome do ficheiro vai
aumentando (no exemplo a cima o
ficheiro default é o mais genérico e o
ficheiro C0A8516 é o mais específico
possível, já que diz respeito a uma
máquina em particular e essas
configurações não são carregadas por
qualquer outra máquina).
Equipamento Utilizado
Para a execução deste projecto o
Departamento de Informática do
Hospital utilizou como clientes (postos
de trabalho) computadores com cerca de
6 anos. São computadores Pentium II a
350MHz, com 32Mb de RAM, placas
gráficas S3 com 4 a 8Mb de memória,
monitores de 15” e 17” polegadas e
placas de rede SMC/3Com. Os discos
rígidos e os CD-ROM´s foram retirados
ou desactivados. Por sua vez, o servidor
de imagens (TFTP) é também o servidor
DHCP. Este servidor é composto por
um Pentium 4 a 2.6GHz, 512Mb de
Ram, um disco de 40Gb e uma placa de
rede Intel. Utiliza o novo sistema
operativo Fedora16
Core 1. Os
servidores utilizados para disponibilizar
o desktop são dois computadores Fujitsu
Simens com um processador Xeon a
2.8GHz e com 2.0GHz de memória
RAM. São compostos ainda com dois
discos de 40Gb. A solução conta ainda
com uma NAS17
com quatro discos
SCSI onde são armazenados todos os
dados dos utilizadores, uma vez que
cada um dos utilizadores tem um share
16
http://fedora.redhat.com 17
Network Attached Storage
no seu ambiente de trabalho que aponta
para a NAS.
Procedimentos de logística
Para garantir o processo de
transformação de um PC obsoleto e
“velho” num equipamento “novo”
obriga a alguns procedimentos de
logística e configuração de software.
Este paper pretende não só dar a
conhecer a eventuais interessados a
solução adoptada mas também orientar
os operacionais do Serviço de
Informática para os procedimentos a ter
na “reciclagem” deste equipamento.
É possível utilizar equipamentos
informáticos, ditos PCs (“Personal
Computers”) com 6 anos ou mais de
vida em plataformas de full desktop
com capacidade de desempenho
semelhante ou melhor a um
microprocessador actual.
Operações de logística do hardware
Os seguintes procedimentos de logística
devem ser executados no início do
processo de “reciclagem” de um PC a
terminal CITRIX.
1- Limpar o interior e exterior do
PC;
2- Garantir unidade máxima de
memória de 32Mb (embora
possa funcionar com apenas 16);
3- Etiquetar o PC;
4- Lacrar o PC;
5- Garantia de que o equipamento
não é colocado no chão ou que
tem protecção de esferovite;
6- Activação da password da
BIOS;
7- Actualizar a base de dados de
stock de equipamento
informático.
8- Informar o administrador de
sistemas do MAC Address da
placa de rede colocada e de que
tipo de PC se trata.
Operações de configuração
Por uma questão de redundância o
arranque poderá ser baseado em duas
alternâncias:
Procedimento PXE
Capacidade de arrancar
directamente a partir da interface de
rede. Arranque mais rápido baseado
na EPROM da placa de rede, e
servidor de imagem/DHCP;
Procedimento HDD
Capacidade de utilizar o disco local.
A mais valia associada ao facto dos
thin clients possuírem disco duro é o
facto de em caso de falha do
servidor de imagens (embora exista
rede) poderem arrancar por disco
com uma imagem idêntica à
carregada remotamente.
Procedimento: PXE
1- Garantir com o administrador de
rede ou com o responsável, qual o
ponto de rede a que deve ser ligado
o futuro “thin client” e qual a sua
localização. Informar ainda qual o
MAC Address da placa de rede que
vai ser instalada bem como o tipo de
equipamento.
2- Assegurar que todos os dados e
ficheiros existentes no disco local
do computador, são colocados na
NAS (Network Attached Storage),
na pasta “Meus Documentos”
referente ao (s) utilizador (es) em
causa, afim de assegurar toda a
informação. Este procedimento deve
ser efectuado também para os e-
mails, favoritos e contactos
existentes no Outlook.
3- Informar o administrador de
sistemas Thin Client se o PC tem
impressora escrava ligada por porta
LPT1 ou, se é impressora partilhada,
ou então se tem configurado uma
impressora baseada em PrintServer.
4- Trocar a placa de rede por uma
tenha suporte PXE e reiniciar o PC.
5- No momento em que o computador
está no processo de arranque
primem-se as teclas Ctrl + ALT + B
para permitir o acesso ao Managed
PC Boot Agent (MBA) da placa de
rede; a configuração standard deve
ser a seguinte:
Boot
Method:
PXE
Config
Message:
Disabled
Message
Timeout:
3 Seconds
Boot Failure
Prompt:
Wait for
timeout
Boot
Failure:
Next boot
device Tabela 1
6- Após estas configurações deve
premir-se a tecla F10 para
gravar as alterações.
7- Entrar no BIOS, mas desta vez
do PC e alterar a sequência de
boot (inicialização) para:
Boot Sequense:
1. [MBA UNDI (Bus0 Slot15)]
2. [Network]
3. [Hard Disk]
4. [Diskette]
5. [CD-ROM]
Tabela 2
Após esta configuração, deve proceder à
gravação da mesma, normalmente com
a tecla F10. Pode variar de BIOS para
BIOS. Reinicia-se o computador.
NOTA: É de salientar que para o
processo de boot por HD (disco local), o
boot Sequence deve ter na primeira
posição a Disquete ou o CD-ROM
(consoante o suporte físico que vai ser
utilizado para o processo). Após o
processo ter terminado, deverá ficar
como a tabela 2 descreve.
Procedimento: (HD)
1- Garantir que o CD-ROM está em
perfeito funcionamento.
2- Garantir que o disco está instalado e
em perfeito funcionamento.
3- Inserir o CD-ROM denominado
“PXE-Image” no leitor.
4- Alterar a boot sequense para que o
CD-ROM seja o primeiro a arrancar.
5- Reiniciar o computador com o CD-
ROM inserido e aguardar que seja
iniciada a configuração
automaticamente.
6- Executar o comando instalar e
aguardar que seja dada a mensagem
para reiniciar o computador.
7- Retirar o CD-ROM e colocar o
disco local na primeira posição do
8- boot sequense (tabela 2) para testar
o seu funcionamento.
9- Confirmar que o arranque é feito
convenientemente através do disco
local.
10- Colocar o boot sequense como
descrito na tabela 2.
Conclusão
A principal vantagem da solução centralizada baseada em CITRIX Vs outra baseada em
Linux nativo ou Sun-Solaris prende-se com a continuidade de disponibilizar aos
utilizadores o mesmo ambiente de trabalho com que sempre estiveram habituados a
efectuar as suas tarefas, a arquitectura Win32, mas principalmente por garantir que
soluções de revendedores capazes de correr no servidor, nomeadamente sobre IE
(Internet Explorer) estão automaticamente habilitadas a correr nos clientes sejam eles
obsoletos ou não.
Continuamos empenhados em melhorar a experiência informática dos utilizadores, com
o menor custo e encontramo-nos à disposição para colaborar com outras instituições que
pretendam implementar soluções idênticas.
Referências
Red-Hat
http://www.redhat.com
Fedora
http://fedora.redhat.com
Bootix
http://www.bootix.com
XFree86
http://www.xfree86.org/
Citrix
http://www.citrix.com
Linux Terminal Server Project
http://www.ltsp.org
Intel
http://www.intel.com
WfM
http://www.intel.com/labs/manage/wfm/
WfM Especifications
http://www.intel.com/labs/manage/wfm/wfmspecs.htm
Argon Technology Corporation
http://www.argontechnology.com
Santa Maria da Feira, Março de 2004
