Terminais Remotos com Linux, Uma Introdução

Uma das mais interessantes características do Linux é a sua versatilidade. A habilidade de poder fazer complicadas configurações out-of-the box. Você não precisa comprar a versão hiper ultimate business para ter a capacidade de montar um complexo sistema cliente/servidor com terminais burros remotos e um servidor de aplicações.

Criar uma rede cliente/servidor é relativamente fácil, devido à arquitetura multi-tarefa/multi usuário nativa do Linux.

Mas, para podermos entender esse processo, é necessário trabalhar com um pouco de teoria, onde veremos o que é uma rede/cliente servidor com terminais burros remotos, quais suas vantagens, em quais casos pode ser usada e de que formas pode ser implementada no Linux.

Um pouco de História

Terminais remotos, anteriormente conhecidos como terminais burros, estão na área das redes há um longo tempo. Eles eram chamados de terminais burros, porque pouco ou nenhum processamento era feito no lado do cliente. Eles simplesmente exibiam a saída do servidor e comunicavam a entrada do usuário através do teclado e / ou mouse de volta para o servidor. O sistema principal era centralizado com todos os dados e os aplicativos sendo armazenados e gerenciados por um único servidor ou um cluster de servidores.

O conceito de processamento central foi amplamente adotado por várias empresas durante os anos 70, devido a vantagens, tais como, tolerância a falhas, a administração central e segurança.

No entanto, como o custo dos PCs diminuiu nos anos 80, a descentralização do sistema com PCs individuais ganhou popularidade. Além disso, os PCs introduziam várias características que terminais burros não possuíam, como uma interface gráfica para o usuário e personalização do sistema pelo usuário.

A Descentralização, por outro lado, fez a gestão, manutenção e atualização do sistema uma tarefa árdua, pois deve ser executada localmente em cada máquina.

Desde o final dos anos 80 a meados dos anos 90, um híbrido de ambos os sistemas, conhecido como cliente / servidor começaou a dominar a cena em rede.

O servidor gerencia o tratamento das informações em banco de dados centralizados, enquanto o cliente PC executa as aplicações e interface do usuário. Dados importantes podem ser facilmente preservados e desempenho foi melhor do que compartilhar os arquivos em um PC comum.

O problema de manutenção, administração e atualização (tanto de aplicativos como o sistema operacional) em PCs individuais continua a ser um dos principais inconvenientes da computação com clientes robustos, já que toda a parte mais crítica acontece no lado cliente.

Uma solução voltando os olhos ao passado

Para resolver diversos problemas da computação distribuída, com o modelo do cliente robusto, surgiu o conceito do thin client, ou cliente magro.

O termo cliente magro foi cunhado em 1993 por Tim Negris, VP de Marketing Server da Oracle Corp, enquanto trabalhava com o fundador da empresa Larry Ellison sobre o lançamento do Oracle 7.

Na época, a Oracle queria diferenciar seu software orientado a servidor dos produtos orientados a desktop da Microsoft. O termo de Negris foi então popularizado pelo seu uso frequente em discursos de Larry Ellison e entrevistas sobre os produtos da Oracle. É dessa época o famoso terminal de internet, o computador de 500 dólares, que a Oracle passou a propagandear e defender.

O termo ficou por várias razões. O termo "terminal gráfico" foi escolhida para contrastar estes terminais com os terminais baseados em texto e, portanto, colocar a ênfase em gráficos.

O termo também não fez muito sucesso entre os profissionais de TI, a maioria dos quais tinha estado trabalhando em sistemas com clientes robustos.

Também transmite melhor a diferença fundamental de hardware: thin clients podem ser projetados com hardware muito mais modesto, porque eles realizam operações muito mais modestas.

As Opções de Hardware

Diversas empresas entraram no segmento dos clientes magros(thin clients) oferecendo soluções em hardware para a implementação de redes com clientes magros:

• ChipPC
• Fujitsu
• HP
• Igel
• LISCON
• OpenThinClient
• Sun Microsystems
• Wyse
• Thinvent 

O Linux nesta História

Ícone do ambiente gráfico do Linux, X

O Linux, por sua própria natureza, sempre foi projetado com o paradigma da rede, do terminal cliente e de um servidor provendo serviços e capacidade pela rede, herdado de seu modelo, o Unix.

E, do Unix, o Linux também herdou o paradigma de ambiente gráfico X.

O ambiente gráfico X começou a ser desenvolvido em 1984, por Jim Gettys e Bob Scheifler.

Havia um esforço conjunto em desenvolver um ambiente gráfico para o Unix e diversas companhias estavam interessadas: IBM, DEC, SUN e HP, apenas para citar algumas. No lado acadêmico, as universidades envolvidas eram: MIT, Carnegie Mellon University, Stanford University e Brown University.

O desenvolvimento do ambiente gráfico do Unix, o X, acabaria por criar um paradigma cliente servidor para a interface gráfica que funciona da seguinte maneira:

Um servidor X se comunica com vários programas clientes. O servidor aceita pedidos de saída gráfica (Windows) e envia de volta a entrada do usuário (a partir do teclado, mouse ou touchscreen).

O servidor pode funcionar como:

• Resultados de um aplicativo para uma janela de um outro sistema de exibição
• Um programa de sistema que controla a saída de vídeo de um PC
• Uma parte específica do hardware.

E, o mais importante dessa arquitetura é que o servidor do ambiente X e os clientes podem estar em máquinas separadas, se comunicando através do protocolo X mesmo que seja por uma rede local.

Representação Gráfica do Esquema de Trabalho do Ambiente X e seu Protocolo

Como discutir sobre a história e o funcionamento do ambiente gráfico X é assunto muito extenso, e, foge ao escopo deste artigo, não iremos adiante agora.

O aspecto interessante da arquitetura do ambiente gráfico X, que depois foi herdado pelo Linux, é que, com ele, é muito fácil criar redes de computadores, terminais burros ligados a um servidor central.

O que nos interessa aqui é o protocolo XDMPC, que foi desenvolvido para a versão X11R4, em 1989, e, introduziu o protocolo como ele hoje é usado, tanto no Linux quanto em outros *NIX .

Vantagens

Redução do custo de propriedade da rede. Entenda o custo de propriedade como o somatório do preço da aquisição do computador, da manutenção, das licenças de uso dos softwares, do consumo de energia elétrica etc.;

• Administração remota de cada terminal;
• Flexibilidade. Se houver alguma falha no hardware do terminal, basta pedir ao usuário para iniciar uma nova sessão gráfica a partir de outro. Assim não haverá perda de informações, pois elas estão centralizadas no servidor;
• Alta escalabilidade. Para aumentar o número de terminais na rede, basta aumentar a capacidade de processamento e a quantidade de memória RAM do servidor;
• É possível personalizar uma sessão gráfica para cada usuário liberando ou restringindo o acesso a determinados recursos ou aplicações do servidor;
• A configuração e a geração da imagem do sistema operacional a ser compartilhado nos terminais pode ser realizada de forma gráfica e flexível, adaptando-a configurações de hardware dos terminais;
• Permite o reuso de computadores obsoletos para serem usados como terminais, reduzindo os custos da rede e diminuindo o impacto ambiental desses equipamentos.

Desvantagens

• Alto tráfego de dados gerado pela comunicação entre o servidor e os terminais da rede;

• O servidor passa a ser o ponto crítico da rede, ou seja, se ele parar de funcionar, todos os usuários ficam impossibilitados de trabalharem;
• O servidor fica mais vulnerável a ataques se um invasor tiver acesso à rede XDMCP.

Onde a rede com servidor/clientes XDMCP pode ser usada:

Redes cliente/servidor XDMCP podem ser implantadas com sucesso em: salas de leitura, bibliotecas, escolas, universidades, telecentros, Cyber cafés, escritórios, em suma, em todas as situações onde o processamento dos dados, entrada e saída, possa ser feito em lotes e de forma síncrona.

Onde a rede XDMCP não pode ser usada:

Processamento multimídia, processamento de dados assíncrono, processamento em tempo real e jogos. Em suma, edição de vídeo, som, modelagem 3D, jogos, não ficam com bom desempenho em uma rede XDMCP.

Nos próximos artigos, vou detalhar como implementar uma rede XDMCP com Linux, aproveitando computadores ultrapassados, que não servem mais para o uso diário.

Até lá!!!