analista de sistema operacional

276
Infraestrutura de TI o que é Infraestrutura?” muitos profissionais da área não sabem responder concretamente, então veremos o conceito, a verdadeira função e sua importância. Origem: latim Infra: interno Estrutura: Alicerce Com a origem da palavra conseguimos seguir um rumo, a Infraestrutura é o alicerce interno de uma empresa, é a base da disponibilização do negócio, NUNCA (palavra perigosa, mas dessa vez está empregada no momento correto), mas NUNCA mesmo, para o próprio interesse da área/departamento, a Infraestrutura de TI existe para dar assistência ao negócio, é o alicerce da empresa e não, a própria empresa, vemos muitos profissionais implantando soluções em suas empresas sem o mínimo impacto de melhoria para o negócio, seja o impacto grande ou pequeno, estão apenas visando a inovação de tecnologia, o layout, a inovação, mas é importante ressaltar que inovação sem aproveitamento não favorecerá a empresa, o departamento de Infraestrutura de TI apenas crescerá SE a empresa crescer e por isso temos que trabalhar a favor do “lucro” da empresa, a Infraestrutura de TI está para DISPONIBILIZAR SERVIÇOS/RECURSOS, MANTER SERVIÇOS existentes e por último, SOLUCIONAR PROBLEMAS dos serviços que auxiliam nos recursos utilizados pelo cliente, seja ele interno ou externo (cliente interno = funcionário, cliente externo = cliente da empresa). Vemos no diagrama abaixo que a TI tem o objetivo final aumentar a competividade da empresa diante do mercado:

Upload: cavaco511

Post on 19-Jan-2016

383 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Analista de Sistema Operacional

Infraestrutura de TI

“o que é Infraestrutura?” muitos profissionais da área não sabem responder

concretamente, então veremos o conceito, a verdadeira função e sua importância.

Origem: latim

Infra: interno

Estrutura: Alicerce

Com a origem da palavra conseguimos seguir um rumo, a Infraestrutura é o

alicerce interno de uma empresa, é a base da disponibilização do negócio, NUNCA

(palavra perigosa, mas dessa vez está empregada no momento correto), mas NUNCA

mesmo, para o próprio interesse da área/departamento, a Infraestrutura de TI existe para

dar assistência ao negócio, é o alicerce da empresa e não, a própria empresa, vemos

muitos profissionais implantando soluções em suas empresas sem o mínimo impacto de

melhoria para o negócio, seja o impacto grande ou pequeno, estão apenas visando a

inovação de tecnologia, o layout, a inovação, mas é importante ressaltar que inovação

sem aproveitamento não favorecerá a empresa, o departamento de Infraestrutura de TI

apenas crescerá SE a empresa crescer e por isso temos que trabalhar a favor do “lucro”

da empresa, a Infraestrutura de TI está para DISPONIBILIZAR

SERVIÇOS/RECURSOS, MANTER SERVIÇOS existentes e por último,

SOLUCIONAR PROBLEMAS dos serviços que auxiliam nos recursos utilizados pelo

cliente, seja ele interno ou externo (cliente interno = funcionário, cliente externo =

cliente da empresa).

Vemos no diagrama abaixo que a TI tem o objetivo final aumentar a

competividade da empresa diante do mercado:

Page 2: Analista de Sistema Operacional

Conceito de negócio e Infraestrutura de TI

EMPRESA/NEGÓCIO precisa de COMPETIVIDADE no mercado, criará

uma ESTRATÉGIA em que a TI terá a INICIATIVA de

CRIAR/MUDAR/MELHORAR o PROCESSO atual visando MELHORAR a

RELAÇÃO com o CLIENTE , onde terá que ter um RESULTADO FINANCEIRO

positivo fazendo que a EMPRESA/NEGÓCIO torne-se mais COMPETITIVA no

mercado.

Apenas fechando a ideia de forma bruta, a TI está para auxiliar a empresa ter

maior competitividade no mercado frente aos concorrentes. As grandes empresas

possuem informações de fornecedores, funcionário e clientes armazenadas e confiadas

na disponibilidade e segurança pela Infraestrutura de TI, existem relatos de empresas

que praticamente começaram do zero por uma falha de TI que ocorreu, comprometendo

toda a informação que eles tinham.

As decisões de Infraestrutura de TI é a mais importante dentro das decisões

relacionadas a TI, os custos de investimentos representam cerca de 55% dos

investimentos da empresa na área de TI.

Page 3: Analista de Sistema Operacional

Sistemas Operacionais

1.1 Introdução Antes de começarmos a estudar os conceitos e os principais componentes de um sistema operacional, devemos saber primeiramente quais são suas funções básicas.

Por mais complexo que possa parecer, um sistema operacional e apenas um conjunto de rotinas executado pelo processador, da mesma forma que qualquer outro programa.. Sua principal função e controlar o funcionamento do computador, como um gerente dos diversos recursos disponíveis no sistema.

O nome sistema operacional não e único para designar esse conjunto de programas. Nomes como monitor, executivo, supervisor ou controlador possuem, normalmente, o mesmo significado.

Um sistema operacional possui inúmeras funções e resumimos essas funções, basicamente, em duas, descritas a seguir:

1.1.1 Facilidade de acesso aos recursos do sistema Um sistema de computacão, ao possui, normalmente, diversos componentes, como terminais,

impressoras, discos e fitas. Quando utilizamos um desses dispositivos, não nos preocupamos com a maneira como e realizada esta comunicação e os inúmeros detalhes envolvidos.

Para a maioria de nós uma operação cotidiana, como, por exemplo, a leitura de um arquivo em disquete, pode parecer simples. Na realidade, existe um conjunto de rotinas específicas, controladas pelo sistema operacional, responsável por acionar a cabeça, a de leitura e gravação da unidade de disco, posicionar na trilha e setor onde estão os dados, transferir os dados do disco para a memória e, finalmente, informar ao programa a chegada dos dados.

O sistema operacional, então, serve de interface entre o usuários e os recursos diponíveis no sistema, tornando esta comunicação transparente e permitindo ao usuário um trabalho mais eficiente e com menores chances de erros (Figura 1).

Este conceito de ambiente simulado, criado pelo sistema operacional, e denominado máquina virtual (virtual machine) e está presente, de alguma forma, na maioria dos sistemas atuais.

É comum pensar-se que compiladores, linkers, bibliotecas, depuradores e outras ferramentas fazem parte do sistema operacional, mas, na realidade, estas facilidades são apenas utilitários, destinados a ajudar a interação do usuário com o computador.

1.1.2 Compartilhamento de recursos de forma organizada e protegida

Quando pensamos em sistemas multiusuário, onde vários usuários podem estar compartilhando os mesmos recursos, como, por exemplo, memória e discos, é necessário que todos tenham oportunidade de ter acesso a esses recursos, de forma que um usuário não interfira no trabalho do outro.

Se imaginarmos, por exemplo, que uma impressora possa ser utilizada por vários usuários do sistema, deverá existir algum controle para impedir que a impressão de um usuário interrompa a impressão de outro. Novamente, o sistema operacional é responsável por permitir o acesso concorrente a esse e a outros recursos, de forma organizada e protegida, dando ao usuário a impressão de ser o único a utilizá-los.

O compartilhamento de recursos permite, também, a diminuição de custos, na medida em que mais de um usuário possa utilizar as mesmas facilidades concorrentemente, como discos, impressoras, linhas de comunicação etc.

Não é apenas em sistemas multiusuário que o sistema operacional é imporntate. Se pensarmos que um computador pessoal nos permite executar várias tarefas, como imprimir um documento, copiar um arquivo pela internet ou processar uma planilha, o sistema operacional deve ser capaz de controlar a execução concorrentes de todas essas tarefas.

Page 4: Analista de Sistema Operacional

Figura 1 - Visão do sistema operacional como interface entre os usuários e os recursos do sistema.

1.2 Máquinas de Níveis Um computador, visto somente como um gabinete composto de circuitos eletrônicos, cabos e fontes de alimentação (hardware), não tem nenhuma utilidade. É através de programas (software) que o computador consegue armazenar dados em discos, imprimir relatórios, gerar gráficos, realizar cálculos, entre outras funções. O hardware é o responsável pela execução das instruções de um programa, com a finalidade de se realizar alguma tarefa. Uma operação efetuada pelo software pode ser implementada em hardware, enquanto uma instrução executada pelo hardware pode ser simulada via software. Esta decisão fica a cargo do projetista do computador em função de aspectos como custo, confiabilidade e desempenho. Tanto o hardware como o software são logicamente equivalentes, interagindo de uma forma única para o usuário. Nos primeiros computadores, a programação era realizada em painéis, através de fios, exigindo um grande conhecimento do hardware e de sua linguagem de máquina. Isso era uma grande dificuldade para os programadores da época. A solução para esse problema foi o surgimento do sistema operacional, que tornou a interação entre usuário e computador mais simples, confiável e eficiente. A partir desse acontecimento, não existia mais a necessidade de o programador se envolver com a complexidade do hardware para poder trabalhar; ou seja, a parte física do computador tornou-se transparente para o usuário.

Page 5: Analista de Sistema Operacional

Figura 2 - Visão modular do computador pelo usuário.

Partindo desse princípio, podemos considerar o computador como uma máquina de níveis ou camadas, onde inicialmente existem dois níveis: o nível 0 (hardware) e o nível 1 (sistema operacional). Desta forma, o usuário pode enxergar a máquina como sendo apenas o sistema operacional, ou seja, como se o hardware não existisse. Esta visão modular e abstrata é chamada máquina virtual. Na realidade, um computador não possui apenas dois níveis, e sim tantos níveis quanto forem necessários para adequar o usuário às suas diversas aplicações. Quando o usuário está trabalhando em um desse níveis, não necessita da existência das outras camadas, acima ou abaixo de sua máquina virtual. Atualmente, a maioria dos computadores possui a estrutura mostrada na Figura, podendo conter mais ou menos camadas. A linguagem utilizada em cada um desses níveis é diferente, variando da mais elementar (baixo nível) à mais sofisticada (alto nível).

Figura 3 - Máquina de níveis.

1.3 Histórico A evolução dos sistemas operacionais está, em grande parte, relacionada ao desenvolvimento de

equipamentos cada vez mais velozes, compactos e de custos baixos, e à necessidade de aproveitamento e controle desses recursos.

Neste histórico dividimos essa evolução em fases, once destacamos, em cada uma, sues principals características de hardware, software, interação com o sistema e aspectos de conectividade.

Sistema Operacional

Hardware

Aplicativos

Utilitários

Sistema Operacional

Linguagem de Máquina

Hadware

Dispositivos Físicos

Microprogramação

Page 6: Analista de Sistema Operacional

1.3.1 Primeira Fase (1945-1955) No início da Segunda Guerra Mundial, surgiram os primeiros computadores digitais, formados

por milhares de válvulas, que ocupavam areas enormes, sendo de funcionamento lento e duvidoso. O ENIAC (Electronic Numerical Integrator and Computer) foi o primeiro computador digital de

propósito geral. Criado pare a realização de cálculos balísticos, sue estrutura possuía 18 mil válvulas, 10 mil capacitores, 70 mil resistores e pesava 30 toneladas. Quando em operação, consumia cerca de 140 quilowatts e era capaz de realizar 5 mil adições por segundo.

Para trabalhar nessas máquinas, era necessário conhecer profundamente o funcionamento do hardware, pods a programação era feita em painéis, através de fios, utilizando linguagem de máquina. Nessa fase, ainda não existia o conceito de sistema operacional.

Outros computadores foram construídos nessa mesma época, como o EDVAC (Electronic Discrete Variable Automatic Computer) e o IAS (Princeton Institute for Advanced Studies), mas eram utilizados, praticamente, apenas nas universidades e nos órgãos militares.

Com o desenvolvimento da indústria de computadores, muitas empresas foram fundadas ou investiram no setor, como a Sperry e a IBM, o que levou a criação dos primeiros computadores pare aplicações comerciais. A primeira máquina fabricada com esse propósito e bem-sucedida foi o UNIVAC I (Universal Automatic Computer), criado especialmente pare o censo americano de 1950.

1.3.2 Segunda Fase (1956-1965) A criação do transistor e das memórias magnéticas contribui pare o enorme avanço dos

computadores da época. O transistor permitiu o aumento da velocidade e da confiabilidade do processamento, e as memórias magnéticas permitiram o acesso mais rápido aos dados, major capacidade de armazenamento e computadores menores.

Com o surgimento das primeiras linguagens de programação, como Assembly e Fortran, os programas deixaram de ser feitos diretamente no hardware, o que facilitou enormemente o processo de desenvolvimento de programas.

Já não era mais possível conviver com tantos procedimentos manuais como os anteriores, que não permitiam o uso eficiente do computador e de seus recursos. Os primeiros sistemas operacionais surgiram, justamente, pare tentar automatizar as tarefas manuais

Figura 4 - Processamento batch

Page 7: Analista de Sistema Operacional

Inicialmente, os programas passaram a ser perfurados em cartões, que, submetidos a uma leitora, eram gravados em uma fita de entrada (Figura 4a). A fita, então, era lida pelo computador, que executava um programa de cada vez, gravando o resultado do processamento em uma fita de saída (Figura 4b). Ao terminar de todos os programas, a fita de saída era lida e impressa (Figura 4c). A esse tipo de processamento, onde um lote (batch) de programas era submetido ao computador, deu-se o nome de processamento batch.

Pode não parecer um avanço, mas anteriormente os programas eram submetidos pelo operador, um a um, fazendo com que o processador ficasse ocioso entre a execução, ao de um programa e outro. Com o processamento batch, um grupo de programas era submetido de uma só vez, o que diminuía o tempo existente entre a execução dos programas, permitindo, assim, melhor uso do processador.

Os sistemas operacionais passaram a ter seu próprio conjunto de rotinas pare operações de entrada/saída (Input/Output Control System—IOCS), que veio facilitar bastante o processo de programação. O IOCS eliminou a necessidade de os programadores desenvolverem sues próprias rotinas de leitura/gravação específicas para cada dispositivo periférico. Essa facilidade de comunicação criou o conceito de independência de dispositivos.

Importantes avanços, em nível de hardware, foram implementados no final dessa fase, principalmente na linha 7094 da IBM. Entre eles, destacamos o conceito de canal, que veio permitir a transferência de dados entre dispositivos de entrada/saída e memória principal de forma independente da UCP. Ainda nessa fase, destacamos os sistemas FMS (Fortran Monitor System) e IBSYS.

1.3.3 Terceira Fase (1966-1980) Através dos circuitos integrados (CIs) e, posteriormente, dos microprocessadores, foi possível

viabilizar e difundir o uso de sistemas computacionais por empresas, devido a diminuição de seus custos de aquisição. Além disso, houve grande aumento do poder de processamento e diminuição no tamanho dos equipamentos.

Com base nessa nova tecnologia, a IBM lançou em 1964 a Série 360. Esse lançamento causou uma revolução na indústria de informática, pois introduzia uma linha (família) de computadores pequena, poderosa e, principalmente, compatível. Isso permitiu que uma empresa adquirisse um modelo mais simples e barato e, conforme sues necessidades, mudasse pare modelos com mais recursos, sem comprometer sues aplicações já existentes. Para essa série, foi desenvolvido o sistema operacional OS/360, que tentava atender todos os tipos de aplicações e periféricos. Apesar de todos os problemas desse equipamento e de seu tamanho físico, a Série 360 introduziu novas técnicas, utilizadas ate hoje.

Na mesma época, a DEC lançou a linha PDP-8, também revolucionária, pois apresentava uma linha de computadores de porte pequeno e baixo custo, se comparada aos mainframes ate então comercializados, criando um novo mercado, o de minicomputadores.

A evolução dos processadores de entrada/saída permitiu que, enquanto um programa esperasse por uma operação de leitura/gravação, o processador executasse um outro programa. Para tal, a memória foi dividida em partições, onde cada programa esperava sue vez pare ser processado. A essa técnica de compartilhamento da memória principal e processador deu-se o nome de multiprogramação.

Com a substituição das fitas por discos no processo de submissão dos programas, o processamento batch tornou-se mais eficiente, pois permitia a alteração na ordem de execução das tarefas, ate então puramente seqüencial. A essa técnica de submissão de programas chamou-se spooling, que, mais tarde, também viria a ser utilizada no processo de impressão.

Os sistemas operacionais, mesmo implementando o processamento batch e a multiprogramação, ao, ainda estavam limitados a processamentos que não exigiam comunicação com o usuário. Para permitir a interação rápida entre o usuário e o computador, foram adicionados terminais de vídeo e teclado (interação on-line).

A multiprogramação evoluiu preocupada em oferecer aos usuários tempos de respostas razoáveis e uma interface cada vez mais amigável. Para tal, cada programa na memória utilizaria o processador em pequenos intervalos de tempo. A esse sistema de divisão de tempo do processador chamou-se time-sharing (tempo compartilhado).

Outro fato importante nessa fase foi o surgimento do sistema operacional Unix (1969). Concebido inicialmente em um minicomputador PDP-7, baseado no sistema MULTICS (Multiplexed Information and Computing Service), o Unix foi depois rescrito em uma linguagem de alto nível (linguagem C), tornando-se conhecido por sue portabilidade.

No final dessa fase, com a evolução dos microprocessadores, surgiram os primeiros microcomputadores, muito mais baratos que qualquer um dos computadores ate então comercializados.

Page 8: Analista de Sistema Operacional

Entre eles, destacamos os micros de 8 bits da Apple e o sistema operacional CP/M (Control Program Monitor).

1.3.4 Quarta Fase (1981-1990) A integração em large escala (Large Scale Integration-LSI) e a integração em muito large escala

(Very Large Scale Integration-VLSI) levaram adiante o projeto de miniaturização e barateamento dos equipamentos. Os mini e superminicomputadores se firmaram no mercado e os microcomputadores ganharam um grande impulso.

Nesse quadro surgiram os microcomputadores PC (Personal Computer) de 16 bits da IBM e o sistema operacional DOS (Disk Operation System), criando a filosofia dos computadores pessoais. Na área dos minis e superminicomputadores ganharam impulso os sistemas multiusuário, com destaque pare os sistemas compatíveis com o Unix (Unix-like) e o VMS (Virtual Memory System) da DEC. Surgem as estações de trabalho (workstations) que, apesar de monousuárias, permitem que se executem diversas tarefas concorrentemente, criando o conceito de multitarefa.

No final dos anos 80, os computadores tiveram um grande avanço, decorrente de aplicações que exigiam um enorme volume de cálculos. Para acelerar o processamento, foram adicionados outros processadores, exigindo dos sistemas operacionais novos mecanismos de controle e sincronismo. Com o multiprocessamento, foi possível a execução de mais de um programa simultaneamente, ou ate de um mesmo programa por mais de um processador. Além de equipamentos com múltiplos processadores, foram introduzidos processadores vetoriais e técnicas de paralelismo em diferentes níveis, fazendo com que os computadores se tornassem ainda mais poderosos.

As redes distribuídas (Wide Area Network- WANs) se difundiram por todo o mundo, permitindo o acesso a outros sistemas de computação, independentemente de estado, país e, ate mesmo, fabricante. Nesse contexto são desenvolvidos inúmeros protocolos de rede, alguns proprietários, como o DECnet da DEC e o SNA (System Network Architecture) da IBM, e outros de domínio público, como o TCP/IP e o CCITT X.25. Surgem as primeiras redes locals (Local Area Network—LANs) interligando pequenas áreas. Os softwares de rede passaram a estar intimamente relacionados ao sistema operacional e surgem os sistemas operacionais de rede.

1.3.5 Quinta Fase (1991- ) Grandes avanços em termos de hardware, software e telecomunicações podem ser esperados ate

o final deste século. Essas mudanças são conseqüência da evolução das aplicações, que necessitam cada vez mais de capacidade de processamento e armazenamento de dados. Sistemas especialistas, sistemas multimídia, banco de dados distribuídos, inteligência artificial e redes neurais são apenas alguns exemplos da necessidade cada vez major.

A evolução da microeletrônica permitirá o desenvolvimento de processadores e memórias cada vez mais velozes e baratos, Além de dispositivos menores, mais rápidos e com major capacidade de armazenamento. Os componentes baseados em tecnologia VLSI (Very Large Scale Integration) evoluem rapidamente pare o ULSI (Ultra Large Scale Integration).

Os computadores da próxima geração têm de ser muito mais eficientes que os atuais, pare atender o volume cada vez major de processamento. Para isso, está ocorrendo uma mudança radical na filosofia de projeto de computadores. Arquiteturas paralelas, baseadas em organizações de multiprocessadores não convencionais, já se encontram em desenvolvimento em varies universidades e centros de pesquisa do mundo.

A evolução do hardware encadeará modificações profundas nas disciplines de programação pare fazer melhor uso das arquiteturas paralelas. Assim, novas linguagens e metodologias de programação concorrentes estão sendo desenvolvidas, em particular, fazendo uso extensivo de inteligência artificial e CAD (Computer-Aided Design).

O conceito de processamento distribuído será explorado nos sistemas operacionais, de forma que sues funções estejam espalhadas por vários processadores através de redes de computadores. Isso só será possível devido a redução, ao dos custos de comunicação e ao aumento na taxa de transmissão de dados.

A arquitetura cliente-servidor aplicada basicamente a redes locais passe a ser oferecida em redes distribuídas, permitindo que qualquer pessoa tenha acesso a todo tipo de informação, independentemente de once esteja armazenada. Problemas de segurança, gerência e desempenho tornam-se fatores importantes relacionados ao sistema operacional e a rede.

A década de 90 foi definitiva pare a consolidação dos sistemas operacionais baseados em interfaces gráficas. Apesar da evolução da interface, a forma de interação com os computadores sofrerá,

Page 9: Analista de Sistema Operacional

talvez, uma das modificações mais visíveis. Novas interfaces homem-máquina serão utilizadas, como linguagens naturais, sons e imagens, fazendo essa comunicação mais inteligente, simples e eficiente. Os conceitos e implementações só vistos em sistemas considerados de grande porte estão sendo introduzidos na maioria dos sistemas desktop, como na família Windows da Microsoft, no Unix e no OS/2 da IBM. Fase Primeira (1945-

1955) Segunda (1956-1965)

Terceira (1966-1980)

Quarta (1981-1990)

Quinta (1991- )

Computadores

ENIAC EDVAC UNIVAK

NCR IMB 7094 CDC-6600

IBM 360, 370 PDP-11 Cray 1 Cyber-205

Cray XMP IBM 308 VAX-11 IBM-PC

IBM 3090 Alpha AXP Pentium Sun SPARC

Hardware Válvulas Tambor Magnético Tubos de raios catódicos

Transistor Memória Magnética

Circuito Integrado Disco Magnético Minicomputador Microprocessador

LSI ou VLSI Disco óptico Microcomputador

Ultra-LSI Arquiteturas Paralelas Circuto Integrado 3-D

Software Linguagem de Máquina Linguagem assembly

Linguagem de Alto Nível Processamento Batch

Linguagem Estruturadas Multiprogramação Time-Sharing Computação Gráfica

Multiprocessamento Sistemas Especialistas Linguagens orientadas a objetos

Processamento Distribuído Linguagens concorrentes Programação funcional Linguagens naturais

Telecomunicações

Telefone Teletipo

Transmissão Digital Comunicação via satélite Microondas Redes distribuídas(WAN) Fibra óptica

Redes Locais (LAN) Internet

Redes Locais estendidas(ELAN) Redes sem fio Modelo cliente-servidor

Desempenho

10 ips 200.000 ips 5 Mips 30 Mips 1 Gflops 1 Tflops

Tabela 1 - Características de cada fase

Page 10: Analista de Sistema Operacional

2. Conceitos de Hardware e Software

2.1 Hardware Um computador digital é constituído por um conjunto de componentes interligados, composto por processadores, memória principal e dispositivos físicos (hardware). Esses dispositivos manipulam dados na forma digital, o que proporciona uma maneira confiável de representação. Todos os componentes de um computador são agrupados em três subsistemas básicos: unidade central de processamento (UCP), memória principal, e dispositivos de entrada e saída (Figura 5. Estes subsistemas, também chamados de unidades funcionais, estão presentes em todo computador digital, apesar de suas implementações variarem nas diferentes arquiteturas existentes e comercializadas pelos diversos fabricantes de computadores. Neste item descrevemos os conceitos básicos dos principais componentes desses sistema.

2.1.1 Unidade Central de Processalmento A unidade central de processamento (UCP), ou processador, tem como função principal unificar

todo o sistema, controlando as funções realizadas por cada unidade funcional. AUCP também é responsável pela execução de todos os programas do sistema, que obrigatoriamente deverão estar armazenados na memória principal.

Um programa é composto por uma série de instruções que são executadas sequencialmente pela UCP, através de operações básicas como somar, subtrair, comparar e movimentar dados. Desta forma, a

UCP busca cada instrução na memória principal e a interpreta para sua execução.

Unidade Lógicae Aritmética

(ULA)

Unidadede Controle

(UC)

RegistradoresDispositivos deEntrada e Saída

Memória Principal (MP)

Figura 5 - Unidades funcionais de um computador

A UCP é composta por dois componentes básicos: unidade de controle e unidade lógica aritmética. A Unidade de controle (UC) é responsável por controlar as atividades de todos os componentes do computador, mediante a emissão de pulsos elétricos (sinais de controle) gerados por um dispositivo denominado clock. Este controle pode ser a gravação de um dado no disco ou a busca de uma instrução da memória. A unidade lógica e aritmética (ULA), como o nome indica, é responsável pela realização de operações lógicas (testes e comparações) e aritméticas (somas e subtrações). A especificação da velocidade de processamento de uma UCP é determinada pelo número de instruções que o processador executa por unidade de tempo, normalmente segundo. Alguns fabricantes utilizam unidade processamento próprias, já que não existe uma padronização, sendo as mais comuns o

Page 11: Analista de Sistema Operacional

MIPS (milhões de instruções por segundo) e o MFLOPS/GFLOPS (milhões/bilhões de instruções de ponto flutuante por segundo). A mostra alguns processadores e suas respectivas velocidades de processamento.

Intel 80386 Intel 80486 Item Pentium Item Pentium Pro Velocidade de Processamento

5 MIPS 20 MIPS 100 MIPS 250 MIPS

Tabela 2 - Velocidade de processamento de alguns computadores.

2.1.2 Clock O clock e um dispositivo, localizado na UCP, que gera pulsos elétricos síncronos em um

determinado intervalo de tempo (sinal de clock). A quantidade de vezes que este pulso se repete em um segundo define a freqüência do clock. O sinal de clock e utilizado pela unidade de controle pare a execução, das instruções.

A freqüência do clock de um processador e medida em Hertz (Hz), que significa o número de pulsos elétricos gerados em um segundo de tempo. A freqüência também pode ser utilizada como unidade de desempenho entre diferentes processadores, pods quanto major a freqüência, mais instruções podem ser executadas pela UCP em um mesmo intervalo de tempo.

2.1.3 Registradores Os registradores são dispositivos de alta velocidade, localizados fisicamente na UCP, pare

armazenamento temporário de dados. O número de registradores varia em função da arquitetura de cada processador. Alguns registradores são de uso específico e têm propósitos especiais, enquanto outros são ditos de uso geral.

Entre os registradores de uso específico, merecem destaque: • contador de instruções (CI) ou program counter (PC) e o registrador responsável pelo armazenamento

do endereço da próxima instrução que a UCP deverá executar. Toda vez que a UCP execute uma instrução, o PC e atualizado com um novo endereço;

• o apontador da pilha (AP) ou stack pointer (SP) e o registrador que contémemóriam o endereço de memória do topo da pilha, que e a estrutura de dados onde o sistema mantém informações sobre tarefas que estavam sendo processadas e tiveram que ser interrompidas por algum motivo;

• o registrador de estado, também chamado em alguns equipamentos de program status word (PSW), e o registrador responsável por armazenar informações sobre a execução do programa, como a ocorrência de carry e overflow. A cada instrução executada, o registrador de estado e alterado conforme o resultado gerado pela instrução.

2.1.4 Memória Principal A memória principal, também conhecida como memória primária ou real, e a parte do

computador onde são armazenados instruções e dados. Ela e composta por unidades de acesso chamadas células, sendo cada célula composta por um determinado número de bits (binary digit). O bit e a unidade básica de memória, podendo assumir o valor 0 ou 1. Atualmente, a grande maioria dos computadores utilize o byte (8 bits) como tamanho de célula, porém encontramos computadores de gerações passadas com células de 16, 32 e ate mesmo 60 bits. Podemos concluir, então, que a memória, e formada por um conjunto de células, onde cada célula possui um determinado número de bits (Figura 6).

Page 12: Analista de Sistema Operacional

0

1

2

M - 1

Célula = n bits

Endereços

Figura 6 - Memória principal

O acesso ao conteúdo de uma célula e realizado através da especificação, ao de um número

chamado endereço. O endereço e uma referência única, que podemos fazer a uma célula de memória Quando um programa deseja ler ou escrever um dado em uma célula, deve primeiro especificar qual o endereço de memória desejado, pare depois realizar a operação.

A especificação, ao do endereço, o e realizada através de um registrador denominado registrador de endereço de memória (memory register address - MAR). através do conteúdo deste registrador, a unidade de controle sabe qual a célula de memória que será acessada. Outro registrador usado em operações com a memória e o registrador de dados da memória (memory buffer register—MBR) . Este registrador e utilizado pare guardar o conteúdo de uma ou mais células de memória após uma operação de leitura, ou pare guardar o dado que será transferido pare a memória em uma operação de gravação. Este ciclo de leitura e gravação e mostrado na Figura 7. Operação de Leitura Operação de gravação

1. A UCP armazena no MAR, o endereço da célula a ser lida. 2. A UCP gera um sinal de controle pare a memória principal, indicando que uma operação de leitura deve ser realizada. 3. 0 conteúdo da(s) célula(s), identificada(s) pelo endereço contido no MAR, e transferido pare o MBR.

1. A UCP armazena no MAR, o endereço da célula que será gravada. 2. A UCP armazena no MBR, a informação que deverá ser gravada. 3. A UCP gera um sinal de controle pare a memória principal, indicando que uma operação de gravação deve ser realizada. 4. A informação contida no MBR e transferida pare a célula de memória endereçada pelo MAR.�

Figura 7 - Ciclo de leitura e gravação

A capacidade de uma memória e limitada pelo tamanho do MAR. No caso de o registrador

possuir n bits, a memória principal poderá no máximo endereçar 2n células, isto é , do endereço 0 ao 2n-1.

A memória principal pode ser classificada em função de sue volatilidade, que e a capacidade de a memória preservar o seu conteúdo mesmo sem uma fonte de alimentação, ao ativa. As memórias chamadas voláteis se caracterizam por poderem ser lidas ou gravadas, como o tipo RAM (random access memory), que constitui quase que a totalidade da memória principal de um computador. O outro tipo,

Page 13: Analista de Sistema Operacional

chamado de não volátil, não permite alterar ou apagar seu conteúdo. Este tipo de memória conhecido como ROM (read-only memory), já vem pré-gravado do fabricante, geralmente com algum programa, e seu conteúdo e preservado mesmo quando a alimentação e desligada. Uma variação da ROM e a EPROM (erasable programmable ROM), once podemos gravar e regravar a memória através exposição de luz ultravioleta por um dispositivo especial.

Atualmente, uma série de memórias com diferentes características, existe pare diversas aplicações, como a EEPROM, EAROM, EAPROM, NOVRAM entre outras.

2.1.5 Memória Cache A MEMÓRIA cache e uma memória volátil de alta velocidade. O tempo de acesso a um dado

nela contido e muito menor que se o mesmo estivesse na memória principal. Toda vez que o processador fez referência a um dado armazenado na memória principal, ele

"olha" antes na memória cache. Se o processador encontrar o dado na cache, não ha necessidade do acesso a memória principal; do contrário, o acesso e obrigatório Neste último cave, o processador, a partir do dado referenciado, transfere um bloco de dados pare a cache. O tempo de transferência entre as memórias e pequeno, se comparado com o aumento do desempenho obtido com a utilização, ao desse tipo de memória.

Apesar de ser uma memória de acesso rápido, seu uso e limitado em fun,cao do alto custo. A Tabela 2.2 mostra a relação entre as memórias cache e principal em alguns equipamentos.

HP 9000/855S IBM 3090/600S VAX 9000/440

Tamanho máximo memória principal

256 Mb 512 Mb 512 Mb

Tamanho máximo Memória cache

256 Kb 128 Kb por UCP 128 Kb por UCP

Tabela 3 - Relação entre as memórias cache e principal

2.1.6 Memória Secundária A memória secundária e um meio permanente (não volátil) de armazenamento de programas e

dados. Enquanto a memória principal precisa estar sempre energizada pare manter sues informações, a memória secundária não precise de alimentação.

O acesso a memória secundária e lento, se comparado com o acesso a memória cache ou à principal, porém seu custo e baixo e sua capacidade de armazenamento e bem superior a da memória principal. Enquanto a unidade de acesso a memória secundária e da ordem de milissegundos, o acesso a memória principal e de nanossegundos. Podemos citar, como exemplos de memórias secundárias, a fita magnética, o disco magnético e o disco óptico.

A Figura 8 mostra a relação entre os diversos tipos de dispositivos de armazenamento apresentados, comparando custo, velocidade e capacidade de armazenamento.

Registradores

Memória Cache

Memória Principal

Memória Secundária

Maior Custo eMaior Velocidadede Acesso

Maior Capacidadede armazenamento

Figura 8 - Relação entre os diversos tipos de dispositivos de armazenamento.

Page 14: Analista de Sistema Operacional

2.1.7 Dispositivos de Entrada e Saída Os dispositivos de entrada e saída (E/S) são utilizados pare permitir a comunicação entre o

computador e o mundo externo. Através desses dispositivos, a UCP e a memória principal podem se comunicar, tanto com usuários quanto com memórias secundárias, a fim de realizar qualquer tipo de processamento.

Os dispositivos de E/S podem ser divididos em duas categorias: os que são utilizados como memória secundária e os que servem pare a interface homem-máquina.

Os dispositivos utilizados como memória secundária, como discos e fitas magnéticas se caracterizam por armazenar de três a quatro vezes mais informações que a memória principal. Seu custo e relativamente baixo, porém o tempo de acesso a memória secundária e de quatro a seis vezes major que o acesso a memória principal.

Alguns dispositivos servem pare a comunicação, ao homem-máquina, como teclados, monitores de vídeo, impressoras, plotters, entre outros. Com o avanço no desenvolvimento de aplicações de uso cada vez mais geral, procure-se aumentar a facilidade de comunicação entre o usuário e o computador. A implementação, de interfaces mais amigáveis permite, cada vez mais, que pessoas sem conhecimento específico sobre informática possam utilizar o computador. Scanner, caneta ótica, mouse, dispositivos sensíveis a voz humana e ao calor do corpo humano são alguns exemplos desses tipos de dispositivos.

2.1.8 Barramento A UCP, a memória principal e os dispositivos de E/S são interligados através de linhas de

comunicação denominadas barramentos, barras ou vias. Um barramento (bus) e um conjunto de fios paralelos (linhas de transmissão), onde trafegam informações, como dados, endereços ou Sinais de controle. Ele pode ser classificado como unidirecional (transmissão em um só sentido) ou bidirecional (transmissão em ambos os sentidos).

Na ligação entre UCP e memória principal, podemos observar que três barramentos são necessários pare que a comunicação seja realizada. O barramento de dados transmite informações entre a memória principal e a UCP. O barramento de endereços e utilizado pela UCP pare especificar o endereço, o da célula de memória que será acessada. Finalmente , o barramento de controle e por onde a UCP envia os pulsos de controle relativos as operações de leitura e gravação.

Na Fig. 2.5, podemos observar dois tipos de configuracões, onde UCP, memória principal e dispositivos de E/S são interligados de maneira diferente.

2.1.9 Pipelining O conceito de processamento pipeline se assemelha muito a uma linha de montagem, onde uma tarefa e dividida em uma seqüência de subtarefas, executadas em diferentes estágios, dentro da linha de produção.

UCP

MemóriaPrincipal

Dispositivosde E/S UCP

MemóriaPrincipal

Dispositivosde E/S

Figura 9 - Configurações de sistema

Da mesma forma que em uma linha de montagem, a execução de uma instrução pode ser dividida em subtarefas, como as fases de busca da instrução e dos operandos, execução e armazenamento dos resultados. O processador, através de suas várias unidades funcionais pipeline, funciona de forma a permitir que, enquanto uma instrução se encontra na fase de execução possa estar na fase de busca simultaneamente.

Page 15: Analista de Sistema Operacional

A técnica de pipelining pode ser empregada em sistemas com um ou mais processadores, em diversos níveis, e tem sido a técnica de paralelismo mais utilizada para maior desempenho dos sistemas de computadores.

2.1.10 Ativação e desativação do Sistema O sistema operacional é essencial para o funcionamento de um computador. Sem ele, grande parte dos recursos do sistema não estaria disponível, ou se apresentaria de uma forma complexa para utilização pelos usuários. Toda vez que um computador é ligado, é necessário que o sistema operacional seja carregado da memória secundária para a memória principal. Esse processo, denominado ativação do sistema (boot), é realizado por um programa localizado em um posição especifíca do disco (disco block), geralmente o primeiro bloco. O procedimento de ativação varia em função do equipamento, podendo ser realizado através do teclado, de um terminal ou por manipulação de chaves de um painel (Figura 10).

Disco MemóriaPrincipal

SistemaOperacional

Boot

Figura 10 - Ativação do sistema

Além da carga do sistema operacional, a ativação do sistema também consiste na execução de arquivos de inicialização. Nestes arquivos são especificados procedimentos de inicialização de hardware e software específicos para cada ambiente. Na maioria dos sistemas, também existe o processo de desativação (shutdown). Este procedimento permite que as aplicações e componentes do sistema sejam desativados de forma ordenada. Garantindo a integridade do sistema.

2.1.11 Arquiteturas RISC e CISC Um processador com arquitetura RISC (Reduced Instruction Set Computer) se caracteriza por possuir poucas instruções de máquina, em geral bastante simples, que são executadas diretamente pelo hardware. Na sua maioria, estas instruções não acessam a memória principal, trabalhando principalmente com registradores que, neste tipo de processador, se apresentam em grande número. Estas características, além de ajudarem as instruções serem executadas em alta velocidade, facilitam a implementação do pipeline. Como exemplos de processaores RISC podemos citar o Sparc (SUN), RS-6000 (IBM), PA-RISC (HP), Alpha AXP (DEC) e Rx000 (MIPS). Os processadores CISC (Complex Instruction Set computers) já possuem instruções complexas que são interpretadas por microprogramas. O número de registradores é pequeno e qualquer instrução pode referenciar a memória principal. Neste tipo de arquitetura, a implementação do pipeline é mais difícil. São exemplos de processadores CISC o VAX (DEC), 80x86 e o Pentium (Intel), e o 68xx (Motorola).

2.2 Software O Hardware por si só não tem a menor utilidade. Para torná-lo útil existe um conjunto de programas, utilizado como interface entre as necessidades do usuário e as capacidades do hardware. A utilização de softwares adequados às diversas tarefas e aplicações (conceitos de camadas) torna o trabalho do usuários muito mais simples e eficiente.

Page 16: Analista de Sistema Operacional

2.2.1 Tradutor Nos sistemas operacionais antigos, o ato de programar era bastante complicado, já que o programador deveria possuir conhecimento do hardware e programar em painéis através de fios. Esses programas eram desenvolvidos em linguagem de máquina e carregados diretamente na memória principal para execução. Com o surgimento das primeiras linguagens de montagem (assembly languages) e das linguagens de alto nível, o programador deixou de se preocupar com muitos aspectos pertinentes ao hardware, como em qual região da memória o programa deveria ser carregado ou quais endereços de memória seriam reservados para as variáveis. A utilização dessas linguagens facilitou a construção de programas em muitos aspectos. Desse modo, um programa poderia ser escrito de uma forma bem documentada e com facilidades para realizar alterações. O tradutor, pelo tipo de linguagem de programação utilizada, pode ser chamado de montador ou compilador (Figura 11).

Programa-Fonte Programa-Fonte Programa-Objeto

Linguagem deMontagem Módulo-Objeto

Módulo-Objeto

Montador

Compilador

Linguagem deAlto Nível

Figura 11 - Tradutor

2.2.2 Compilador É o utilitário responsável por gerar, a partir de um programa escrito em uma linguagem de alto nível, um programa em linguagem de máquina não executável. As linguagens de alto nível, como pascal, fortran, cobol não tem nenhuma relação direta com a máquina, ficando essa preocupação exclusivamente com o compilador.

2.2.3 Interpretador O interpretador é considerado um tradutor que não gera código-objeto. A partir de um programa fonte, escrito em linguagem de alto nível, o interpretador, no momento da execução do programa, traduz cada instrução e a executa em seguida.

2.2.4 Linker O linker (ligador), também chamado de linkagem, é o utilitário responsável por gerar, a partir de um ou mais módulos-objetos, um único programa executável.

Page 17: Analista de Sistema Operacional

Figura 12 - Linker.

2.2.5 Loader Também chamado carregador é o utilitário responsável por colocar fisicamente na memória um programa para execução. O procedimento de carga varia com o código gerado pelo linker e, em função deste, o loader é classificado como sendo do tipo absoluto ou relocável. Tipo absoluto - o loader só necessita conhecer o endereço de memória inicial e o tamanho do módulo para realizar o carregamento. Então, ele transfere o programa da memória secundária para a memória principal e inicia sua execução. No caso de código relocável, o programa pode ser carregado em qualquer posição de memória, e o loader é responsável pela relocação no momento do carregamento.

2.2.6 Depurador O desenvolvimento de programas está sujeito a erros de lógica, independentemente de metodologias utilizadas pelo programador. A depuração é um dos estágios desse desenvolvimento, e a utilização de ferramentas adequadas é essencial para acelerar o processo de correção de programas. O depurador (debbuger) é o utilitário que permite ao usuário controlar a execução de um programa a fim de detectar erros na sua estrutura. Este utilitário oferece ao usuário recursos como: • Acompanhar a execução de um programa instrução por instrução; • Possibilitar a alteração e visualização do conteúdo de variáveis; • Implementar pontos de parada dentro do programa (break-point), de forma que, durante a execução, o

programa pare nesses pontos; • Especificar que, toda vez que o conteúdo de uma variável for modificado, o programa envie uma

mensagem (watchpoint).

2.2.7 Linguagem de Controle Também denominada a linguagem de comando, e a forma mais direta de um usuário se comunicar com o sistema operacional. Esta linguagem é oferecida por cada sistema operacional para que, através de comandos simples, o usuário possa ter acesso a rotinas especificas do sistema.

2.2.8 Interpretador de Comandos (Shell) O sistema operacional é o código executor de chamadas de sistema. Os editores, compiladores, montadores, ligadores e interpretadores de comando não fazem parte do sistema operacional, apesar de serem softwares muito importantes e muito úteis. Esses comandos quando digitados pelos usuários, são interpretados pelo Shell, verifica sua sintaxe, envia mensagens de erro e faz chamadas a rotinas do sistema. Dessa forma o usuário dispõe de uma interface interativa com o sistema operacional, para realizar tarefas como acessar uma arquivo em disco ou consultar um diretório.

Programa Executável

Módulo Objeto Compilador

Módulo Fonte

Módulo Objeto

Módulo Fonte Linker Compilador

Módulo Objeto

Módulo Fonte Compilador

Page 18: Analista de Sistema Operacional

2.2.9 Linguagem de Máquina A linguagem de máquina de um computador é a linguagem de programação que o processador realmente consegue entender. Cada processador possui um conjunto único de instruções de máquina, definido pelo próprio fabricante. As instruções especificam detalhes, como registradores, modos de endereçamento e tipos de dados, que caracterizam um processador e suas potencialidades.

2.2.10 Microprogramação Um programa em linguagem de máquina é executado diretamente pelo hardware em processadores de arquitetura RISC, porém em máquinas CISC isto não acontece. Neste caso, como podemos observar na Figura 3, entre os níveis de linguagem de máquina e do hardware, existem ainda o da microprogramação. Os microprogramas definem a linguagem de máquina de cada computador. Apesar de cada computador possui níveis de microprogramação diferentes, existem muitas semelhanças nessa camada se compararmos os diversos equipamentos. Uma máquina possui, aproximadamente 25 microintruções básicas, que são interpretadas pelos circuitos eletrônicos.

2.2.11 Processos Um conceito chave da teoria dos sistemas operacionais é o conceito de processo. Um processo é basicamente um programa em execução, sendo constituído do código executável, dos dados referentes ao código.

2.2.12 Chamadas de Sistema Os programas de usuário solicitam serviços do sistema operacional através da execução de chamadas de sistema. A cada chamada corresponde um procedimento de uma biblioteca de procedimentos que o programa do usuário pode chamar.

2.2.13 Arquivos Arquivos são mecanismos de abstração que fornece uma forma de armazenar recuperar informações em disco. Isto deve ser feito de uma forma que mantenha o usuário isolado dos detalhes a respeito de como as informações são armazenadas, e de como os discos efetivamente trabalha.

Page 19: Analista de Sistema Operacional

3. Tipos de Sistemas Operacionais

3.1 Introdução Tipos de sistemas operacionais e sua evolução estão intimamente relacionados com a evolução do hardware e das aplicações por ele suportadas. Muitos termos inicialmente introduzidos para definir conceitos e técnicas forma substituídos por outros, na tentativa de refletir uma nova maneira de interaçã ou ou processamento. Isto fica muito claro quanto tratamos da unidade de execução do processador. Inicialmente, os termos programa ou job eram os mais utilizados, depois surgiu o conceito de processo e subprocesso e, mais recentemente, os conceitos de tarefa e de thread. A evolução dos sistemas operacionais para computadores pessoais e estações de trabalho popularizou vários conceitos e técnicas, antes só conhecidos em ambientes de grande porte. A nomenclatura, no entanto, não se manteve a mesma. Surgiram novos termos para conceitos já conhecidos, que foram apenas adaptados para uma nova realidade.

Tipos de SistemasOperacionais

SistemasMonoprogamáveis/

Monotarefa

SistemasMultiprogramáveis/

Multitarefa

Sistemas comMúltiplos

Processadores

Figura 13 - Tipos de sistemas operacionais

Tipos de Sistemas Operacionais Sistemas Monoprogramáveis/Monotarefa Sistemas Multiprogramáveis/Multitarefa Sistemas Batch Sistemas de Tempo Compartilhado Sistemas de Tempo Real Sistemas com Múltiplos Processadores Sistemas Fortemente Acoplados Sistemas Simétricos Sistemas Assimétricos Sistemas Fracamente Acoplados Sistemas Operacionais de Rede Sistemas Operacionais Distribuídos

3.2 Sistemas Monoprogramáveis/Monotarefa Os primeiros sistemas operacionais eram tipicamente voltados para a execução de um único programa (job). Qualquer outro programa, para ser executado, deveria aguardar o término do programa corrente. Os sistemas monoprogramáveis, como vieram a ser conhecidos, se caracterizam por permitir que o processador, a memória e os periféricos permaneçam exclusivamente dedicados à execução de um único programa. Neste tipo de sistema, enquanto um programa aguarda por um evento, como a digitação de um dado, o processador permanece ocioso, sem realizar qualquer tipo de processamento. A memória é

Page 20: Analista de Sistema Operacional

subtilizada caso o programa não a preencha totalmente, e os periféricos, como discos e impressoras, estão dedicados a um único usuário. Comparados a outros sistemas, os sistemas monoprogramáveis/monotarefa são de simples implementação, não existindo muita preocupação com problemas de proteção.

UCP

Memória

Dispositivosde E/S

Programa/Tarefa

Figura 14 - Sistemas monoprogramáveis/monotarefa

3.3 Sistemas Multiprogramáveis/Multitarefa Os Sistemas Multiprogramáveis, que vieram a substituir os monoprogramáveis, são mais complexos e eficientes. Enquanto em sistemas monoprogramáveis existe apenas um programa utilizando seus diversos recursos, nos multiprogramáveis vários programas dividem esses mesmos recursos. As vantagens do uso de sistemas multiprogramáveis são o aumento da produtividade dos seus usuários e a redução de custos, a partir do compartilhamento dos diversos recursos do sistema. A partir do número de usuários que interagem com o sistema, podemos classificar os sistemas multiprogramáveis como monousuário e multiusuário. O conceito de sistemas multiprogramável está tipicamente associado aos mainframes e minicomputadores, onde existe a idéia do sistema sendo utilizado por vários usuários (multiusuário). No mundo dos computadores pessoais e estações de trabalho, apesar de existir apenas um único usuário interagindo como sistema (monousuário), é possível que ele execute diversas tarefas concorrentemente ou mesmo simultaneamente. Os sistemas multitarefa, como também são chamados, se caracterizam por permitir que o usuário edite um texto, imprima um arquivo, copie um arquivo pela rede e calcule uma planilha. Abaixo estão relacionados os tipos de sistemas em função do número de usuários

Um usuário Dois ou mais usuários Monoprogramação/ Monotarefa

Monousuário N/A

Multiprogramação/ Multitarefa

Monousuário Multiusuário

Tabela 4 - Sistemas X Usuários

Os sistemas multiprogramáveis/multitarefa podem ser classificados pela forma com que suas aplicações são gerenciadas, podendo ser divididos em sistemas batch, de tempo compartilhado ou de tempo real. Um sistema operacional pode suportar um ou mais desses tipos de processamento.

Page 21: Analista de Sistema Operacional

SistemasMultiprogramáveis/Multirefa

Sistemas

Batch

Sistemas de

Tempo compartilhado

Sistemas de

Tempo Real

Figura 15 - Tipos de sistemas multiprogramáveis/multitarefa

3.3.1 Sistemas Batch Os sistemas batch (lote) foram os primeiros sistemas multiprogramáveis a serem implementados e caracterizam-se por terem seus programas, quando submetidos, armazenados em disco ou fita, onde esperam para ser executados seqüencialmente. Normalmente, os programas, também chamados de jobs, não exigem interação com os usuários, lendo e gravando dados em discos e fitas. Alguns exemplos de aplicações originalmente processadas em batch são compilações, linkedições, sorts, backups e todas aquelas onde não é necessária a interação com o usuário.

3.3.2 Sistemas de Tempo Compartilhado Os sistemas de tempo compartilhado (time-sharing) permitem a interação dos usuários com o sistema, basicamente através de terminais que incluem vídeo, teclado e mouse. Dessa forma, o usuário pode interagir diretamente com o sistema em cada fase do desenvolvimento de suas aplicações e, se preciso, modificá-las imediatamente. Devido a esse tipo de interação, os sistemas de tempo compartilhado também ficaram conhecidos como sistemas on-line. Para cada usuário, o sistema operacional aloca uma fatia de tempo (time-slice) do processador. Caso o programa do usuário não esteja concluído nesse intervalo de tempo, ele é substituído por um de outro usuário, e fica esperando por uma nova fatia de tempo. Não só o processador é compartilhado nesse sistema, mas também a memória e os periféricos, como discos e impressoras. O sistema cria para o usuário um ambiente de trabalho próprio, dando a impressão de que todo o sistema está dedicado, exclusivamente, a ele. Sistemas de tempo compartilhado são de implementação complexa, porém, se levado em consideração o tempo de desenvolvimento e depuração de uma aplicação, aumentam consideravelmente a produtividade dos seus usuários, reduzindo os custos de utilização do sistema.

3.3.3 Sistemas de Tempo Real Os sistemas de tempo real (real time) são bem semelhantes em implementação aos sistemas de tempo compartilhado. A maior diferença é o tempo de resposta exigido no processamento das aplicações. Enquanto em sistemas de tempo compartilhado o tempo de resposta pode variar sem comprometer as aplicações em execução, nos sistemas de tempo real os tempos de resposta devem estar dentro de limites rígidos, que devem ser obedecidos, caso contrário poderão ocorrer problemas irreparáveis. Não existe idéia de fatia de tempo, um programa detém o processador o tempo que for necessário, ou até que apareça outro prioritário em função de sua importância no sistema. Esta importância ou prioridade de execução é controlada pela própria aplicação e não pelo sistema operacional, como nos sistemas de tempo compartilhado. Esses sistemas, normalmente, estão presentes em controle de processos, como no monitoramento de refinarias de petróleo, controle de tráfego aéreo, de usinas termelétricas e nucleares, ou em qualquer aplicação onde o tempo de resposta é fator fundamental.

3.4 Sistemas com Múltiplos Processadores Os sistemas com múltiplos processadores caracterizam-se por possuir duas ou mais UCPS interligadas, trabalhando em conjunto. Um fator-chave no desenvolvimento de sistemas operacionais com múltiplos processadores é a forma de comunicação entre as UCPs e o grau de compartilhamento da

Page 22: Analista de Sistema Operacional

memória e dos dispositivos de entrada e saída. Em função desses fatores, podemos classificar os sistemas em fortemente acoplados ou fracamente acoplados.

Sistemas com MúltiplosProcessadores

Sistemas FracamenteAcoplados

Sistemas FortementeAcoplados

SistemasOperacionaisDistribuídos

SistemasOperacionais de Rede

SistemasSimétricos

SistemasAssimétricos

Figura 16 - Sistemas com múltiplos processadores.

3.5 Sistemas Fortemente Acoplados Nos sistemas fortemente acoplados (tightly coupled) existem vários processadores compartilhando uma única memória e gerenciados por apenas um sistema operacional. Múltiplos processadores permitem que vários programas sejam executados ao mesmo tempo, ou que um programa seja dividido em subprogramas, para execução simultânea em mais de um processador. Dessa forma, é possível ampliar a capacidade de computação de um sistema, adicionando-se apenas novos processadores, com um custo muito inferior à aquisição de outros computadores. Com o multiprocessamento, novos problemas de concorrência foram introduzidos, pois vários processadores podem estar acessando as mesmas áreas de memória. Além disso, existe o problema de organizar de forma eficiente os processadores, a memória e os periféricos. Uma conseqüência do multiprocessamento foi o surgimento dos computadores voltados, principalmente, para processamento científico, aplicado, por exemplo, ao desenvolvimento aeroespacial, prospeção de petróleo, simulações, processamento de imagens e CAD. A princípio qualquer aplicação que faça uso intensivo da UCP será beneficiada pelo acréscimo de processadores ao sistema.

UCP

Memória

Dispositivosde E/S

UCP

Dispositivosde E/S

Figura 17 - Sistemas fortemente acoplados

Page 23: Analista de Sistema Operacional

UCP

Memória Dispositivosde E/S

UCP

Memória Dispositivosde E/S

Link de Comunicação

Figura 18 - Sistemas fracamente acoplados

3.5.1 Sistemas Assimétricos Na organização assimétrica ou mestre/escravo(master/slave), somente um processador (mestre) pode executar serviços do sistema operacional, como, por exemplo, realizar operações de entrada/saída. Sempre que um processador do tipo escravo precisar realizar uma operação de entrada/saída, terá de requisitar o serviço ao processador mestre. Dependendo do volume de operações de entrada/saída destinadas aos processadores escravos, o sistema pode se tornar ineficiente, devido ao elevado número de interrupções que deverão ser tratadas pelo mestre.

UCP SlaveUCP Master

Dispositivosde E/S S.O

Usuários Usuários

Figura 19 - Sistemas assimétricos.

Se o processador falhar, todo o sistema ficará incapaz de continuar o processamento. Neste caso, o sistema deve ser reconfigurado, fazendo um dos processadores escravos assumir o papel do mestre. Mesmo sendo uma organização simples de implementar e quase um extensão dos sistemas multiprogramáveis, esse tipo de sistema não utiliza eficientemente o hardware, devido à assimetria dos processadores, que não realizam as mesmas funções.

3.5.2 Sistemas Simétricos O multiprocessamento simétrico (Simmetric Multiprocessing- SMP), ao contrário da organização mestre/escravo, implementa a simetria dos processadores, ou seja, todos os processadores realizam as mesmas funções. Apenas algumas poucas funções ficam a cargo de um único processador, como, por exemplo, a inicialiazação (boot) do sistema.

Page 24: Analista de Sistema Operacional

UCPUCP

Dispositivosde E/S S.O

Usuários

Figura 20 - Sistemas simétricos.

Como vários processadores estão utilizando, independentemente, a mesma memória e o mesmo sistema operacional, é natural a ocorrência de acessos simultâneos às mesmas áreas de memória. A solução desses conflitos fica a cargo do hardware e do sistema operacional. No processamento simétrico, um programa pode ser executado por qualquer processador, inclusive por vários processadores ao mesmo tempo (paralelismo). Além disso, quando um processador falha, o sistema continua em funcionamento sem nenhuma interferência manual, porém com menor capacidade de computação. Os sistemas simétricos são mais poderosos que os assimétricos, permitindo um melhor balanceamento do processamento e das operações de entrada/saída, apesar de sua implementação ser bastante complexa.

3.5.3 Multiprocessamento Desde sua criação, os computadores têm sido vistos como máquinas seqüências, onde a UCP

executa a instruções de um programa, uma de cada vez. Na realidade, essa visão não é totalmente verdadeira, pois, em nível de hardware, múltiplos sinais estão ativos simultaneamente, o que pode ser entendido como uma forma de paralelismo.

Com a implementação de sistemas com múltiplos processadores, o conceito de simultaneidade ou paralelismo pode ser expandido a um nível mais amplo, denominado multiprocessamento, onde uma tarefa pode ser dividida e executada, ao mesmo tempo, por mais de um processador.

3.5.4 Organização Funcional O esquema de comunicação interna das UCPs, memória e dipositivos de E/S (unidades

funcionais) é fundamental no projeto de sistemas com múltiplos processadores, pois termina quantas UCPs o sistema poderá ter e como será o acesso à memória.

Para permitir múltiplos acessos simultâneos à memória (interliving), é comum que esta dividida em módulos, podendo assim ser compartilhada por várias unidades funcionais. As organizações funcionais de multiprocessadores podem ser divididas basicamente em três tipos: barramento comum, barramento cruzado e memória multiport.

3.6 Sistemas Fracamente Acoplados Os sistemas fracamente acoplados caracterizam-se por possuir dois ou mais sistemas de computação interligados, sendo que cada sistema possui o seu próprio sistema operacional, gerenciando os seus recursos, como processador, memória e dispositivos de entrada/saída. Até meados da década de 80, os sistemas operacionais e as aplicações suportadas por eles eram tipicamente concentradas em sistemas de grande porte, com um ou mais processadores. Nos sistemas centralizados, os usuários utilizam terminais não inteligentes conectados a linhas seriais dedicadas ou linhas telefônicas públicas para a comunicação interativa com esses sistemas. No modelo centralizado, os terminais não têm capacidade de processamento. Sempre um usuário deseja alguma tarefa, o pedido é encaminhado ao sistema, que realiza o processamento e retorna uma resposta, utilizando as linhas de comunicação. Com a evolução dos computadores pessoais e das estações de trabalho, juntamente com o avanço das telecomunicações e da tecnologia de redes, surgiu um novo modelo de computação, chamado de modelo de rede de computadores.

Page 25: Analista de Sistema Operacional

Rede

Nó Nó

Figura 21- Sistemas fracamente acoplados

3.6.1 Sistemas Operacionais de Rede Em sistemas operacionais de rede (SOR), cada nó possui seu próprio sistema operacional, além de um hardware e software que possibilitam ao sistema ter acesso a outros componentes da rede, compartilhando seus recursos. O SOR permite entre outras funções:

• Cópia remota de arquivos • Emulação de terminal • Impressão remota • Gerência remota • Correio eletrônico.

Cada nó é totalmente independente do outro, podendo inclusive possuir sistemas operacionais diferentes. Caso a conexão entre os nós sofra qualquer problema, os sistemas podem continuar operando normalmente, apesar de alguns recursos se tornarem indisponíveis. O melhor exemplo da utilização dos sistemas operacionais de rede são as redes locais. Nesse ambiente, cada estação pode compartilhar seus recursos com o restante da rede. Caso uma estação sofra qualquer, os demais componentes da rede podem continuar o processamento, apenas não dispondo dos recursos oferecidos por ela.

Figura 22 - Sistemas operacionais de rede.

3.6.2 Sistemas Operacionais distribuídos Em sistemas distribuídos, cada componente da rede também possui seu próprio sistema operacional, memória, processador e dispositivos. O que define um sistema distribuído é a existência de um relacionamento mais forte entre os seus componentes, onde geralmente os sistemas operacionais são os mesmos. Para o usuário e suas aplicações, é como se não existisse uma rede de computadores, mas sim um único sistema centralizado.

Page 26: Analista de Sistema Operacional

Rede

Usuário

Figura 23 - Sistemas Operacionais Distribuídos.

A grande vantagem desses sistemas é a possibilidade do balanceamento de carga, ou seja, quando um programa é admitido para execução, a carga de processamento de cada sistema é avaliada e o processador mais livre é escolhido. Depois de aceito para processamento, o programa é executado no mesmo processador até o seu término. Também é possível o compartilhamento de impressoras, discos e fitas, independentemente do sistema em que a aplicação esteja sendo processada. Este tipo de sistema distribuído é muitas vezes chamado de cluster.

COMP 2COMP 1

Figura 24 - Cluster.

Suponha, por exemplo, uma configuração de dois computadores (COMP 1 e COMP 2), formando um cluster. Qualquer usuário conectado ao cluster poderá ter acesso aos dispositivos compartilhados, que permitem a ele imprimir uma listagem ou copiar um arquivo. Nesse tipo de configuração, se um dos sistemas falhar, o acesso aos dispositivos não será interrompido. Os sistemas distribuídos podem ser considerados como uma evolução dos sistemas fortemente acoplados, onde uma aplicação pode ser executada por qualquer processador. Os sistemas distribuídos permitem que uma aplicação seja dividida em diferentes partes (aplicações distribuídas), que se comunicam através de linhas de comunicação, podendo cada parte ser processada em um sistema independente.

Page 27: Analista de Sistema Operacional

3.6.3 Organização Funcional A organização funcional dos sistemas fracamente acoplados ou topologia define como são

interligados fisicamente os diversos sistemas da rede.

3.6.3.1 Barramento Na organização de barramento, os sistemas são conectados a uma única linha de comunicação e

todos compartilham o mesmo meio, tanto para receber como para enviar mensagens. Esse tipo de organização é utilizada geralmente em redes locais (Figura 25).

Neste tipo de topologia, caso haja algum problema com o meio de transmissão, todos os nós da rede ficarão incomunicáveis.

Figura 25 - Organização de Barramento

3.6.3.2 Organização distribuída Na organização distribuída existem linhas de comunicação ponto-a-ponto que ligam os sistemas e

caminhos alternativos entre os diversos nós da rede. Caso uma linha de comunicação apresente problema, linhas alternativas permitirão que a rede continue em funcionamento. Este tipo de organização é utilizada geralmente em redes distríbuídas (Figura 26).

Figura 26 - Organização distribuída

Page 28: Analista de Sistema Operacional

4. Sistemas Multiprogramáveis

A possibilidade de periféricos funcionarem simultaneamente entre si, juntamente com a UCP, permitiu a execução de tarefas concorrentes, que é o princípio básico para projeto e implementação de sistemas multiprogramáveis. Sistemas operacionais podem ser vistos como um conjunto de rotinas que executam concorrentemente de uma forma ordenada. Os sistemas multiprogramáveis surgiram de um problema existente nos sistemas monoprogramáveis, que é a baixa utilização de recursos do sistema, como processador, memória e periféricos. Nos sistemas monoprogramáveis, somente um programa pode estar residente em memória, e a UCP permanece dedicada, exclusivamente, à execução desse programa. Podemos observar que, nesse tipo de sistema, ocorre um desperdício na utilização da UCP, pois enquanto o programa está realizando, por exemplo, uma leitura em disco, o processador permanece sem realizar nenhuma tarefa. O tempo de espera é consideravelmente grande, já que as operações com dispositivos de entrada e saída são muito lentas se comparadas com a velocidade da UCP. Na tabela abaixo, vemos um exemplo de um programa que lê registros de uma arquivo e executa, em média, 100 instruções de máquina por registro lido. Neste caso, o processador gasta 93% do tempo esperando o dispositivo de E/S concluir a operação para continuar o processamento. Em um sistema monoprogramável, a UCP é utilizada em aproximadamente 30% do tempo, enquanto em sistemas multiprogramáveis o tempo de utilização sobre para até 90%.

Leitura de um registro 0,0015 segundos Execução de 100 instruções 0,0001 segundos Total 0.0016 segundos Percentual de utilização da UCP 0,0001 = 0,066 = 6,6% 0,0015

Tabela 5 - Exemplo de utilização do sistema

Outro aspecto que devemos considerar é a subutilização da memória. Um programa que não ocupe totalmente a memória principal ocasiona a existência de áreas livres, sem utilização. Nos sistemas multiprogramáveis, vários programas podem estar residentes em memória, concorrendo pela utilização da UCP. Dessa forma, quando um programa solicita uma operação de entrada/saída, outros programas poderão estar disponíveis para utilizar o processador. Nesse caso, a UCP permanece menos tempo ociosa e a memória principal é utilizada de forma mais eficiente, pois existem vários programas residentes se revezando na utilização do processador. A utilização concorrente da UCP deve ser implementada de maneira que, quando um programa perde o uso do processador e depois retorna para continuar o processamento, seu estado deve ser idêntico ao do momento em que foi interrompido. O programa deverá continuar sua execução exatamente na instrução seguinte àquela em que havia parado, aparentando ao usuário que nada aconteceu. Em sistemas de tempo compartilhado, existe a impressão de que o computador está inteiramente dedicado ao usuário, ficando todo esse mecanismo transparente para ele. No caso de periféricos, é comum termos, em sistemas monoprogramáveis, impressoras paradas por um grande período de tempo e discos com acesso restrito a um único usuário. Esses problemas são solucionados em sistemas multiprogramáveis, onde é possível compartilhar impressoras entre vários usuários e realizar acesso concorrente a discos por diversos programas.

Page 29: Analista de Sistema Operacional

E/S

Livre

tempo

UCP

E/S

tempo

UCP

1

11

2

Sistema Nomoprogramável (a) Sistema Multiprogramável (b)

E/S

Livre

tempo

UCP

E/S

tempo

UCP

1

11

2

Figura 27 - Sistema monoprogramável X multiprogramável.

As vantagens de periféricos pela multiprogramação podem ser percebidas segundo o exemplo descrito a seguir, onde consideramos um computador de 256 Kb de memória, com um disco , um terminal e uma impressora. Nesta configuração serão executadas três programas (Prog1, Prog2, e Prog3), que possuem características de processamento descritas na Tabela 6. Nesta tabela, podemos notar que o Prog1 não realiza operações de E/S, enquanto o Prog2 e o Prog3 realizam muitos acessos a periféricos. Características Prog1 Prog2 Prog3 Utilização da UCP Grande Baixa Baixa Operações de E/S Poucas Muitas Muitas Tempo para execução 5 min. 15 min. 10 min. Espaço da memória utilizado 50 Kb 100Kb 80Kb Utiliza disco Não Não Não Utiliza terminal Não Sim Não Utiliza impressora Não Não Sim

Tabela 6 - Características dos programas exemplos

Em um ambiente monoprogramável, os programas são executados sequencialmente. Sendo assim, o Prog1 completa em cinco minutos e o Prog2 deve esperar cinco minutos para começar sua execução, que leva 15 minutos. Finalmente, o Prog3 inicia sua execução após 20 minutos e completa seu processamento em 10 minutos, perfazendo um total de 30 minutos para a execução dos programas. No caso de os programas serem executados concorrentemente, em um sistema multiprogramável, o ganho na utilização do processador, memória, periféricos e no tempo de reposta é considerável, como mostra a Tabela 7. Monoprogramação Multiprogramação Utilização da UCP 17 % 33% Utilização da memória 30 % 67% Utilização do disco 33 % 67% Utilização da impressora 33 % 67 % Tempo total para execução dos programas 30 min. 15 min. Taxa de execução de programas 6 prog./hora 12 prog./hora

Tabela 7 - Comparação entre monoprogramação x multiprogramação

4.1 Interrupção e Exceção Durante a execução de um programa, alguns eventos podem ocorrer durante seu processamento, obrigando a intervenção do sistema operacional. Esse tipo de intervenção é chamado interrupção ou exceção e pode ser resultado da execução de instruções do próprio programa, gerado pelo sistema operacional ou por algum dispositivo de hardware. Nestas situações o fluxo de execução do programa é desviado para uma rotina especial de tratamento. O que diferencia uma interrupção de uma exceção é o tipo de evento que gera esta condição.

Page 30: Analista de Sistema Operacional

Uma interrupção é gerada pelo sistema operacional ou por algum dispositivo e, neste caso, independe do programa que está sendo executado. Um exemplo é quando um periférico avisa à UCP que está pronto para transmitir algum dado. Neste caso, a UCP deve interromper o programa para atender a solicitação do dispositivo.

Interrupção

.

.

.

.

.

.

.

.

.

.

.

.

Salva osregistradores

Identifica a origemda interrupção

Rotina deTratamentoObtém o endereço da

rotina de tratamento :::

Restauraos registradores

Programa

Figura 28 - Mecanismo de interrupção.

Não existe apenas um único tipo de interrupção e sim diferentes tipos que devem ser atendidos por diversas rotinas de tratamento. No momento que uma interrupção acontece, a UCP deve saber para qual rotina de tratamento deverá ser desviado o fluxo de execução. Essa informação está em uma estrutura do sistema chamada vetor de interrupção, que contém a relação de todas as rotinas de tratamento existentes, associadas a cada tipo de interrupção. A interrupção é o mecanismo que tornou possível a implementação da concorrência nos computadores, sendo o fundamento básico dos sistemas multiprogramáveis. É em função desse mecanismo que o sistema operacional sincroniza a execução de todas as suas rotinas e dos programas dos usuários, além de controlar os periféricos e dispositivos do sistema. Inicialmente os sistemas operacionais apenas implementavam o mecanismo de interrupção. Com a evolução dos sistemas foi introduzido o conceito de exceção. Uma exceção é resultado direto da execução de uma instrução do próprio programa. Situações como a divisão de um número por zero ou a ocorrência de um overflow caracterizavam essa situação. A diferença fundamental entre exceção e interrupção é que a primeira é gerada por um evento síncrono, enquanto a segunda é gerada por eventos assíncronos. Um evento é síncrono quando é resultado direto da execução do programa corrente. Tais eventos são previsíveis e, por definição só podem ocorrer um de cada vez. Se um programa que causa esse tipo de evento for reexecutado, com a mesma entrada de dados, a exceção ocorrerá sempre na mesma instrução. Um evento é dito assíncrono quando ocorre independentemente da execução do programa corrente. Esses eventos, por serem imprevisíveis, podem ocorrer múltiplas vezes simultaneamente, como no caso de diversos dispositivos de E/S informarem à UCP que estão prontos para receber ou transmitir dados.

4.2 Operações de Entrada/Saída Em sistemas mais primitivos, a comunicação entre a UCP e os periféricos era controlada por um conjunto de instruções especiais, denominadas instruções de entrada / saída, executadas pela própria UCP. Essas instruções continham detalhes específicos de cada periférico, como quais trilhas e setores de um

Page 31: Analista de Sistema Operacional

disco deveriam ser lidos ou gravados em determinado bloco de dados. Esse tipo de instrução limitava a comunicação do processador a um grupo particular de dispositivos. A implementação de um dispositivo chamado controlador ou interface permitiu à UCP agir de maneira independente dos dispositivos de E/S. Com esse novo elemento, a UCP não se comunicava mais diretamente com os periféricos, mas sim através do controlador. Isso significa as instruções de E/S, por não ser mais preciso especificar detalhes de operação dos periféricos, tarefa esta realizada pelo controlador.

UCP MemóriaPrincipal

Controlador

::::

Figura 29 - Controlador.

Com a implementação do mecanismo de interrupção no hardware dos computadores, as operações de E/S puderam ser realizadas de uma forma mais eficiente. Em vez de o sistema periodicamente verificar o estado de uma operação pendente, o próprio controlador interrompia a UCP para avisar do término da operação. Com esse mecanismo, denominado E/S controlada por interrupção, a UCP, após a execução de um comando de leitura ou gravação, fica livre para o processamento de outras tarefas. O controlador por sua vez, ao receber, por exemplo, um sinal de leitura, fica encarregado de ler os blocos dos disco e armazená-los em memória ou registradores próprios. Em seguida, o controlador, através de uma linha de controle, sinaliza uma interrupção ao processador. Quando a UCP atende a interrupção, a rotina responsável pelo tratamento desse tipo de interrupção transfere os dados dos registradores do controlador para a memória principal. Ao término da transferência, a UCP volta a executar o programa interrompido e o controlador fica novamente disponível para outra operação. A operação de E/S controlada por interrupção é muito mais eficiente que a operação de E/S controlada por programa, já que elimina a necessidade de a UCP esperar pelo término da operação, além de permitir que várias operações de E/S sejam executadas simultaneamente. Apesar disso, essa implementação ainda sobrecarregava a UCP, uma vez que toda transferência de dados entre memória e periféricos exigia a intervenção da UCP. A solução desse problema foi a implementação, por parte do controlador, de uma técnica de transferência de dados denominada DMA (Direct Memory Access). A técnica de DMA permite que bloco de dados seja transferido entre memória e periféricos, sem a intervenção da UCP, exceto no início e no final da transferência. Quando o sistema deseja ler ou gravar um bloco de dados, são passadas da UCP para o controlador informações como: onde o dado está localizado, qual o dispositivo de E/S envolvido na operação, posição inicial da memória de onde os dados serão lidos ou gravados e o tamanho do bloco de dados. Com estas informações, o controlador realiza a transferência entre o periférico e a memória principal, e a UCP é somente interrompida no final da operação. A área de memória utilizada pelo controlador na técnica de DMA é chamada buffer, sendo reservada exclusivamente para este propósito. No momento em que a transferência de DMA é realizada, o controlador deve assumir, momentaneamente, o controle do barramento. Como a utilização do barramento é exclusiva de um dispositivo, a UCP deve suspender o acesso ao bus, temporariamente, durante a operação de transferência. Este procedimento não gera uma interrupção, e a UCP pode realizar tarefas, desde que sem a utilização do barramento, como, por exemplo, um acesso à memória cache. A extensão do conceito do DMA possibilitou o surgimento dos canais de E/S, ou somente canais, introduzidos pela IBM no Sistema 7094. O canal de E/S é um processador com capacidade de executar programas de E/S, permitindo o controle total sobre operações de entrada e saída. As instruções de E/S são armazenadas na memória principal pela UCP, porém o canal é responsável pela sua execução. Assim,

Page 32: Analista de Sistema Operacional

a UCP realiza uma operação de E/S, instruindo o canal para executar um programa localizado na memória (programa de canal). Este programa especifica os dispositivos para transferência, buffers e ações a serem tomadas em caso de erros. O canal de E/S realiza a transferência e, ao final gera uma interrupção, avisando do término da operação. Um canal de E/S pode controlar múltiplos dispositivos através de diversos controladores. Cada dispositivo, ou conjunto de dispositivos, é manipulado por um único controlador. O canal atua como um elo de ligação entre a UCP e o controlador.

UCP MemóriaPrincipal

Cana deE/S

. . . . .

Controlador

. . . . .

Controlador

Figura 30 - Canal de E/S

4.3 Buffering A técnica de buffering consiste na utilização de uma área de memória para a transferência de dados entre os periféricos e a memória principal denominada buffer. O buffering veio permitir que, quando um dado fosse transferido para o buffer após uma operação de leitura, o dispositivo de entrada pudesse iniciar uma nova leitura. Neste caso, enquanto a UCP manipula o dado localizado no buffer, o dispositivo de entrada pudesse iniciar uma nova leitura. Neste caso, enquanto a UCP manipula o dado localizado no buffer, o dispositivo realiza outra operação de leitura no mesmo instante. O mesmo raciocínio pode ser aplicado para operações de gravação, onde a UCP coloca o dado no buffer para um dispositivo de saída manipular.

BufferControlador

de E/SUCP

Memória Principal

GravaçãoGravação

LeituraLeitura

Figura 31 - Operações utilizando buffer.

O buffering é outra implementação para minimizar o problema da disparidade da velocidade de processamento existente entre a UCP e os dispositivos de E/S. O objetivo do buffering é manter, na maior parte do tempo, UCP e dispositivos de E/S ocupados.

Page 33: Analista de Sistema Operacional

A unidade de transferência usada no mecanismo de buffering é o registro. O tamanho do registro pode ser especificado em função da natureza do dispositivo ( como uma linha gerada por uma impressora ou um caracter de um teclado) ou da aplicação ( como um registro lógico definido em um arquivo). O buffer deve possuir a capacidade de armazenar diversos registros, de forma a permitir que existam dados lidos no buffer, mas ainda não processados (operações de leitura), ou processados, mas ainda não gravados (operação de gravação). Desta forma, o dispositivo de entrada poderá ler diversos registros antes que a UCP os processe, ou a UCP poderá processar diversos registros antes de o dispositivo de saída realizar a gravação. Isso é extremamente eficiente, pois, dessa maneira, é possível compatibilizar a diferença existente entre o tempo em que a UCP processa os dados e o tempo em que o dispositivo de E/S realiza as operações de leitura e gravação.

4.4 Spooling A técnica de spooling (simultaneous peripheral operation on-line) foi introduzida no final dos anos 50 para aumentar a produtividade e a eficiência dos sistemas operacionais. Naquela época, os programas dos usuários eram submetidos um a um para processamento pelo operador. Como a velocidade de operação dos dispositivos de entrada/saída é muito lenta se comparada à do processador, era comum que a UCP ficasse ociosa à espera de programas e dados de entrada ou pelo término de uma impressão. A solução foi armazenar os vários programas e seus dados, também chamados de jobs, em uma fita magnética e, em seguida, submetê-los a processamento. Desta forma, a UCP poderia processar seqüencialmente cada job, diminuindo o tempo de execução dos jobs e o tempo de transição entre eles. Da mesma forma, em vez de um job gravar suas saídas diretamente na impressora, poderia direcioná-las para uma outra fita, que depois seria impressa integralmente. Esta forma de processamento é chamada de spooling e foi a base dos sistemas batch. A utilização de fitas magnéticas obrigava o processamento a ser estritamente seqüência, ou seja, o primeiro job a ser gravado era o primeiro a ser processado. Assim, se um job que levasse várias horas antecedesse pequenos jobs, seus tempos de resposta ficariam seriamente comprometidos. Com o surgimento de dispositivos de acesso direto, como discos, foi possível tornar o spooling muito mais eficiente, e principalmente, permitir a eliminação do processamento estritamente seqüencial, com a atribuição de prioridade aos jobs. A técnica de buffering, como já apresentamos, permite que um job utilize um buffer concorrentemente com um dispositivo de E/S. O spooling, basicamente, utiliza o disco como um grande buffer, permitindo que dados sejam lidos e gravados em disco, enquanto outros jobs são processados. Um exemplo dessa técnica está presente quanto impressora são utilizadas. No momento em que um comando de impressão é executado por um programa, as informações que serão impressas são gravadas em um arquivo em disco (arquivo de spool), para ser impresso posteriormente pelo sistema Figura 32. Dessa forma, situações como a de um programa reservar a impressora, imprimir uma linha e ficar horas para continuar a impressão não acontecerão. Essa implementação permite maior grau de conpartilhamento na utilização de impressoras.

SistemaOperacionalPrograma

Impressão

Arquivo de Spool

Figura 32 - Técnico de spooling.

Atualmente, a técnica de spooling é implementada na maioria dos sistemas operacionais. Fazendo com que tanto a UCP quanto os dispositivos de E/S seja aproveitados de forma mais eficiente.

4.5 Reentrância É comum, em sistemas multiprogramáveis, vários usuários executarem os mesmos utilitários do sistema operacional simultaneamente, como, por exemplo, um editor de textos. Se cada usuário que

Page 34: Analista de Sistema Operacional

utilizasse o editor trouxesse o código do utilitário para a memória, haveria diversas cópias de um mesmo programa na memória principal, o que ocasionaria um desperdício de espaço. Reentrância é a capacidade de um código de programa (código reentrante) poder ser compartilhado por diversos usuários, exigindo que apenas uma cópia do programa esteja na memória. Uma característica da reentrância é que o código não pode ser modificado por nenhum usuário no momento em que está sendo executado. A reentrância permite que cada usuário possa estar em um ponto diferente do código reentrante, manipulando dados próprios, exclusivos de cada usuários.

4.6 Proteção do Sistema Nos sistemas multiprogramáveis, onde diversos usuários compartilham os mesmo recursos, deve existir uma preocupação, por parte do sistema operacional, de garantir a integridade dos dados pertencentes a cada usuário. Problemas como um programa acessar (acidentalmente ou não) a área de memória pertencente a outro programa ou ao próprio sistema operacional tornaria o sistema pouco confiável. Para isso, todo sistema implementa algum tipo de proteção aos diversos recursos que são compartilhados, como memória, dispositivos de E/S e UCP. Com vários programas ocupam a memória simultaneamente e cada usuário possui uma área onde dados e código são armazenados, os sistema operacional deve possuir mecanismos de proteção à memória, de forma a preservar as informações. Caso um programa tente acessar uma posição de memória fora da sua área, um erro do tipo violação de acesso ocorre e o programa é encerrado. O mecanismo para o controle de acesso à memória varia em função do tipo de gerência de memória implementado pelo sistema. Há outro problema quando um programa reserva um periférico para realizar alguma operação. Neste situação, como, por exemplo, na utilização de uma impressora, nenhum outro programa deve interferir até que o programa libere. O compartilhamento de dispositivos de E/S deve ser controlado de forma centralizada pelo sistema operacional. Para solucionar esses diversos problemas, o sistema operacional deve implementar mecanismos de proteção que controlem o acesso concorrente aos diversos recursos do sistema. Esse mecanismo de proteção, implementado na maioria dos sistemas multiprogramáveis, é denominado modos de acesso.

Page 35: Analista de Sistema Operacional

5. Estrutura dos Sistemas Operacionais

Existe uma grande dificuldade em compreender a estrutura e o funcionamento de um sistema operacional, pois ele não é executado como uma aplicação tipicamente seqüencial, com início, meio e fim. As rotinas do sistema são executadas sem uma ordem predefinida, baseada em eventos dissociados do tempo (eventos assíncronos). Muitos desses eventos estão relacionados ao hardware e tarefas internas do próprio sistema operacional. O sistema operacional é formado por um conjunto de rotinas (procedimentos) que oferecem serviços aos usuários do sistema e suas aplicações, bem como a outras rotinas do próprio sistema. Esse conjunto de rotinas é chamado núcleo do sistema ou Kernel (cérebro). As principais funções do núcleo são:

• tratamento de interrupções; • criação e eliminação de processos; • sincronização e comunicação de processos; • escalonamento e controle dos processos; • gerência de memória; • gerência do sistema de arquivos; • operações de entrada e saída; • contabilização e segurança do sistema.

5.1 System Calls Uma preocupação que surge na grande maioria dos projetos de sistemas operacionais é a implementação de mecanismos de proteção ao núcleo do sistema e de acesso aos seus serviços. Caso uma aplicação, que tenha acesso ao núcleo, realize uma operação que o danifique, todo o sistema poderá ficar comprometido e inoperante. O usuário (ou aplicação), quando deseja solicitar algum serviço do sistema, realiza uma chamada a uma de suas rotinas ( ou serviços) através de system calls (chamadas ao sistema), que são a porta de entrada para se ter acesso ao núcleo do sistema operacional. Para cada serviço existe uma system call associada e cada sistema operacional tem o seu próprio conjunto (biblioteca) de chamadas, com nomes, parâmetros e formas de ativação específicos (Figura 33).

HardwareAplicaçãoSystem

Call Núcleo

Figura 33 - System Call

Através dos parâmetros fornecidos na system call, a solicitação é processada e uma resposta é retornada à aplicação, em um dos parâmetros fornecidos na chamada. O mecanismo de ativação e comunicação entre a aplicação e o sistema é semelhante ao mecanismo implementado quando um programa modularizado ativa um dos seus procedimentos ou funções. As system call podem ser divididas em grupos de função: * Gerência de processos Criação e eliminação de processos Alteração das características do processo Sincronização e comunicação entre processos * Gerência de memória Alocação e desalocação de memória *Gerência de entrada/saída Operações de entrada/saída

Page 36: Analista de Sistema Operacional

Manipulação de arquivos e diretórios

5.2 Modos de Acesso Existem certas instruções que não podem ser colocadas diretamente à disposição das aplicações, pois a sua utilização indevida ocasionaria sérios problemas à integridade do sistema. Suponha que uma aplicação deseja atualizar um arquivo em disco. O programa, por si só, não pode especificar diretamente as instruções que acessam seus dados. Como o disco é um recurso compartilhado, sua utilização deverá ser realizada unicamente pelo sistema operacional, evitando que a aplicação possa ter acesso a qualquer a qualquer área do disco indiscriminadamente, o que poderia comprometer a segurança do sistema. Como visto, fica claro que existem certas instruções, como operações de entrada e saída, que só devem ser executadas pelo sistema operacional, para impedir a ocorrência de problemas de segurança e mesmo violação do sistema. As instruções que têm o poder de comprometer o sistema são conhecidas como instruções privilegiadas, enquanto as instruções não privilegiadas são as que não oferecem perigo ao sistema. Para que uma aplicação possa executar uma instrução privilegiada, o processador implementa o mecanismo de modos de acesso. Existem basicamente dois modos de acesso implementados pelo processador: modo usuário e modo kernel. Quando um processador trabalha no modo usuário, uma aplicação só pode executar instruções não privilegiadas, tendo acesso a um número reduzido de instruções, enquanto no modo kernel a aplicação pode ter acesso ao conjunto total de instruções do processador. O modo de acesso de uma aplicação é determinado por um conjunto de bits, localizado em um registrador especial da UCP, que indica o modo de acesso corrente. Através desse registrador, o hardware verifica se a instrução pode ou não ser executada pela aplicação. A melhor maneira de controlar o acesso às instruções privilegiadas é permitir que apenas o sistema operacional tenha acesso a elas. Sempre que uma aplicação necessita de um serviço que incorra em risco para o sistema, a solicitação é feita através de uma system call. A system call altera o modo de acesso do processador para um modo mais privilegiado (modo kernel). Ao término da rotina do sistema, o modo de acesso é retornado para o modo usuário (Figura 34). Caso um programa tente executar uma instrução privilegiada, sem o processador estar no modo kernel, uma execeção é gerada e o programa é encerrado.

Figura 34 - Chamada a uma rotina do sistema

5.3 Tipos de Estrutura de Sistemas Operacionais Vamos examinar quatro maneiras diferentes de se estruturar um sistema operacional, do modo a formar uma idéia a respeito do espectro de possibilidades

5.3.1 Sistemas Monolíticos Apesar da estrutura monolítica ser de longe a mais utilizada, ela poderia muito bem ser chamada de “a grande confusão”. Simplesmente não há estruturação visível na organização monolítica. O sistema operacional é escrito como um conjunto de procedimentos, cada um dos quais podendo chamar qualquer dos demais sempre que necessário. Quando esta técnica é usada, cada procedimento do sistema deve ter uma interface bem definida em termos de parâmetros e de resultados, sendo, conforme mencionado

Page 37: Analista de Sistema Operacional

anteriormente, cada procedimento livre para chamar qualquer outro se este último realizar algo de que o primeiro necessite. Ex. MS-DOS, UNIX

Figura 35 - Sistemas monolíticos.

5.3.2 Sistemas em Camadas Um sistema em camadas divide o sistema operacional em camadas sobrepostas. Cada módulo oferece um conjunto de funções que podem ser utilizadas por outros módulos. Módulos de uma camada podem fazer referência apenas a módulos das camadas inferiores. O primeiro sistema com base nesta abordagem foi o sistema THE (Techinische Hogeschool Eindhoven), construído por Dijkstra na Holanda em 1968 e que utilizava seis camadas. Posteriormente, os sistemas MULTICS e VMS também implementaram o conceito de camadas, sendo estas concêntricas. Neste tipo de implementação, as camadas mais internas são mais privilegiadas que as mais externas.

Operador5

Programas de Usuário4

Entrada/Saída3

Comunicação2

Gerência de memória1

Multiprogramação0

Figura 36 - Sistema MULTICS

A vantagem da estruturação em camadas é isolar as funções do sistema operacional facilitando sua alteração sua alteração e depuração, além de criar uma hierarquia de níveis de modos de acesso, protegendo as camadas mais internas.

Page 38: Analista de Sistema Operacional

Usuário

Supervisor

Executivo

Kernel

Figura 37 - Sistema VMS.

5.3.3 Máquinas Virtuais Chamado originalmente de CP/CMS, agora denominado VM/370 (Seawright and MacKinnon, 1979), baseou-se numa astuta observação: um sistema de compartilhamento de tempo deve fornecer: (1) ambiente para multiprogramação e (2) uma máquina estendida com uma interface mais conveniente que o hardware. A essência do VM/370 é a separação completa destas duas funções. O coração conhecido como monitor da máquina virtual, roda sobre o hardware, e implementa a multiprogramação, fornecendo não só uma, mas várias máquinas virtuais para o nível acima dele. Porém, ao contrário dos demais sistemas operacionais, estas máquinas não são máquinas estendidas, com sistemas de arquivos e outras características agradáveis e convenientes ao usuário. Em vez disso, elas são cópias fiéis do hardware, incluindo os modos kernel/usuário, entrada/saída, interrupções, e tudo o mais que uma máquina real possui. Pelo fato de cada máquina virtual ser uma cópia exata do hardware, cada uma delas pode rodar um sistema operacional. Máquinas virtuais diferentes podem rodar sistemas operacionais diferentes. Algumas rodam sistemas sucessores do OS/360 para processamento batch, outras rodam um sistema monousuário, outras um sistema interativo denominado CMS (Conversational Monitor System) para usuários de sistemas de compartilhamento de tempo. Quando um programa CMS executa uma chamada de sistema, a chamada é interceptada pelo sistema operacional de sua própria máquina virtual, não pelo VM/370, exatamente como se ele estivesse rodando numa máquina real, e não numa virtual. O CMS então executa as instruções necessárias para efetuar a chamada. Estas instruções são interceptadas pelo VM/370, que as executa como parte da simulação do hardware real. Através da completa separação das funções de fornecimento do ambiente de multiprogramação e do fornecimento de uma máquina virtual, cada um dos módulos é mais simples, mais flexível e mais fácil de manter.

5.3.4 Modelo Cliente Servidor Uma tendência dos sistemas operacionais modernos é tornar o núcleo do sistema operacional o menor e mais simples possível. Para implementar esta idéia, o sistema é dividido em processos, sendo cada um responsável por oferecer um conjunto de serviços, como serviços de arquivos, serviços de criação de processos, serviços de memória, serviços de escalonamento, etc. Sempre que uma aplicação deseja algum serviço, ela solicita ao processo responsável. Neste caso, a aplicação que solicita um serviço é chamada de cliente, enquanto o processo que responde à solicitação é chamado servidor. Um cliente, que pode ser uma aplicação de um usuário ou um outro componente do sistema operacional, solicita um serviço enviando uma mensagem para o servidor. O servidor responde ao cliente através de uma outra mensagem. É função do núcleo do sistema realizar a comunicação ou seja, a troca de mensagens entre o cliente e o servidor.

Page 39: Analista de Sistema Operacional

Núcleo

Hardware

Cliente

Servidorde arquivo

Servidorde memória

Servidorde processo

Servidorde rede

Modo usuário

Modo kernel

Figura 38 -Sistemas cliente-servidor.

A utilização deste modelo permite que os servidores executem em modo usuário, ou seja, não tenham acesso direto a certos componentes do sistema. Apenas o núcleo do sistema, responsável pela comunicação entre clientes e servidores, executa no modo kernel. Como conseqüência, se um erro ocorrer em um servidor, este servidor pode parar, mas o sistema não ficará inteiramente comprometido. Além disso, a implementação de sistemas cliente-servidor permite isolar as funções do sistema operacional por diversos processos (servidores) pequenos e dedicados a serviços específicos. Como conseqüência, os sistema operacional passa a ser de mais fácil manutenção. Como os servidores se comunicam através de trocas de mensagens, não importa se os clientes e servidores estão sendo processados em um sistema com um único processador, com múltiplos processadores (fortemente acoplado) ou ainda em um ambiente de sistema distribuído (fracamente acoplado). A implementação de sistemas cliente-servidor em um ambiente distribuído permite que um cliente solicite um serviço e a resposta seja processada remotamente. Apesar de todas as vantagens deste modelo, sua implementação, na prática, é muito difícil devido a certas funções do sistema operacional exigirem acesso direto ao hardware, como operações de entrada e saída. Na realidade, o que é implementado mais usualmente é uma combinação do modelo de camadas com o modelo cliente-servidor. O núcleo do sistema, além de ser responsável pela comunicação entre cliente e servidor, passa a incorporar outras funções críticas do sistema, como escalonamento e gerência de memória, além das funções dos device drivers.

Page 40: Analista de Sistema Operacional

������������������� ��������� ���������� ������������������������������ ��������� ����������������� �������� ������������������ ����������������������������� ����� ������������������������������ ���������������� ������������ ��������� �����! �������������������������" �������� ��#��� ����������������$���������������������� �������!����������� %���������� ������������������������������������������������������������������������ ����������� ��������������������������������������� �!&��������������������'���������������(������� ��� ����������)���������������$������!�� ��������'�����*� �������(����������������������������������������+����� � ���)���������������� ���������,������� ���(������������"� ������� ��������� ��������������������-����� .-������������-/���0 ���-����������������� �� ������1 2��� �����, !������� ��� ��������������"� ������� ����������� ����� ���������������� �����������&�!�����3�����&�����41 2��� ����56��� � �+71 8���������2����� 71 8����"� ������� ������������������� ��� ������71 9��������������3��,�%�471 0��,������" �������.���71 8���������������� �����'�����������������71 9�����������:�"���������3;�" � ���4������������������������<��=� ������, ���������������56��� � 71 * )������ �������� ������������������>� �� ����+71 ?��6���3 �""���4������ �, ����������'������������������3<��������� �<������ ��6�����4��������������������71 *���� ��� ������2��� ����56��� � �+7@ABCDEFAGHIJGECAGHDHCKLKCFDLMGFECKGHNAHGEGFDOKHAPDLKCEABKQHREBNASGHT

Page 41: Analista de Sistema Operacional

��� ���������� �� ������������������������������������ ����������� ������������� ��� �� ���������� ��!����"�� #�������$����� ����������%� ����� ���� ���������%���� ������� & �����$��������������'�(��� #���%���������)����� ������������������������������ *���� �����$����� ��+��,+�)����-�������& ��� ��)����$�& ��� �����& ��� ���(������ �� ����. ������ ����/��0�������������� ����1�� ���������� ������������ 2�����������������������������+������3�����4�������������� ����'����� $����$����������� �������������)�������� �� �����$������������� �� ��������5�����������)������������������ ������������������������ ���������� ������ �)� ������������������������������ ������� ���� ����������6������57�6��� ���+�������� ��� ��������� �������8���������$� ��� ��& �������� ��9����������:����;��+�����������������6������ ����� ��<5�� ���� ���������!)��� �����������0��)��� ������������� ����%��� �����������:��������������������������������� �������������� ����=���)�����������������+������� �� ��������5���>��� ����1)������������� ����'����)������9����� ���������� �������� �������*��)���?����� �������� ������)� ������ �����@�����������$��� ����� ������������������)������ ����������������*���3������� �� ��������������������)������������������������������������������������ ������ �5�%�������$�� ���������������������*��)��� ��3�������

Page 42: Analista de Sistema Operacional

������������������������ ������������������������������������������������������������� ����������������������������������������������������������������� �������������������������� ���������!��������������������"������������������������������������������#����������������������������������������������������������������������������������������������������� ����������������������������#���������������$������������������������������������������������������������������������������������"����������������$�� ����������%�����

Page 43: Analista de Sistema Operacional

�������������� ����������������������������� �����!�����������"��������������#��$��#%���#&'�("�����#�)("#��#����%�����#������*��#�����%#�#�"�"*�������#������ ����+����,����-����"�'���-��!������#&���.&���#��/�0��#������ ���#$������#��1#��#� ������"�#�$#�#��"��#'�%������,����-����"�'�("��)�"�#�����+��2*��%#'��#�����3�#����"���$#�#�"�"*�����("���+��#$������#��3�#�������%�����#���/������"����%"������+��#�!#%�&��#���$#�#��"#��#��1��#������*��#��%���#���1#��#1�3#�+���#�*��#������#2#&4�'���"�"*����$����#2�������$��3�#�#���#����*$��#���!#%�&����������%����#�������%"�������("���#���"�#��������#����/�5���#���"#��6$�����%�#��#���2��#����*$��#'�!*%�&�����3"�#����("���"�%#�%�����7��������06$&�����8'�#��������#��"�����������"��$��3�#�#�����59�!#1����������3�#�#��������("����'�%���#�59��#�7����������%��#��!#%�&������"�#���������)���%#���%���%�#����"��%��$"�#������#�"�#���$������#�%�����:�"$��;��)���%�/<*���-��!������#&�#$������#���������������%"�����#��%���#��������"�����("�������6#���#���%��$&����%������"�"*����$�����6�%"�#��1*�����$��3�#�#�����$���"��1��#��������������=-����>������������=-'�%���%�#�?���#�������%��$��#��1#��!#%�&��������%����#�����3"�#��#�%�����7�3���������;��@������#&)�����A#%B"$���C���#"�#�+������������������#���%����#���������#��#������ ��'�)�$���@1�&�!#D���2#%B"$����"�#���������)���%#��"�%��$��#��1#/���.&���#����#�2)��#$������#���������������%"�����#%���%���������"�����("������#���"#�!"�%���#&��#���%��$&��#�%��������������%"��������$��@1��������#�1���+�����������#��$��#%���#&�%����#E"�#�$#�#�$����3�������#���������"�%��$"�#������������$�����1������#��#D��#������$���*�����%����#�$���#��"���"2��

Page 44: Analista de Sistema Operacional

������������������ ������������������������������������������������������������������������������� ��������������� �! ����"������#�$����������������������������%����&��'��(��#�����������)���������������������������� ��������*������"������)+�������������������$�%����&��,����$������-��������)���#����������������-�����)��$�#������ ����#����������������.�/(�������������������� ���������0�1��������0 ���������2������� �������,����������3��$����)��+�����������������������������)���4������%����&�$��(�����*�3���5� �����������������������#�����6 �����)��������� ����������)��������������� �������7��)������3���8���3�����������9:��;:�<=�>?@?:A:�B*�#�.���� ��3��������.��������� �������������������������������������C(�� �������������������������� ������ ������������ ���� ����������� ������������ ������� ���������!���0�%����&��'�)�������#�������������#��/4��� ��������5������������#�����������������������DEFGHIJHKLMNOPH6����)Q�������$��� �����3���)��+����������������������� ����������������������R������������������/(��������)*���������/4���)������ �� ����������3������#��������������������������*3��������*� �������� ���������#������ ���������.������� ����������

Page 45: Analista de Sistema Operacional

����������������� ������� ������������������������������������������������������������������� ������������������������������������ ���� ��������������������������������������������������� ������������������� ��!"#$%&"'&()"#%$*%+*,-".�/����0��1��� 2��������������� ��������������3������� ������������������� � �����������������������������4�����.������������ � ���������5���� ������������������� ������ ������������� ����������� �����������3�������������������������������� ���������� ������� ��������� ���������������� ����.�6�����4��7�����/����0��1���������8�� ���������� �������8��������� ���������3�������� ������.�9������������������������� �������������� ��������������������� ����:���������3������� ������������0������ ��������������������������������� ������;���������<�������������������������������������� ���������������� ��������3�������=� ����� ��������� ����������������

Page 46: Analista de Sistema Operacional

�������������� ������ ������������� � �� ��� �������� ������������ !�"��#$%�&'()*+*,-*,./+-0'(+-(,1.2'3-+4'1+-('56-7'*,-+81)1-*)1,/+9,0/,-:9-+1;:)('-1,5,0/,3-.,9-0,9-+'-9,0'.-+81)1-'-71'41+9+-;:,-('56-:/)<)=':>-?)4+9'.-;:,-('56-,./+(+-,*)/+0*'-:9-1,<+/@1)'-,9-.,:-,*)/'1-*,-/,A/'-,-71,5).':-B,5CDE<'-7'1-+<4:9-9'/)('>-F:+0*'-;:).,1-('</+1-+-/1+8+<C+1-0,<,3-8+./+-5<)5+1-5'9-'-8'/2'-*)1,)/'-.'8-'-G5'0,-*'-,*)/'1-,-'-+1;:)('-,./+1D-,0/1,-'.-1,5,0/,.>H'-)0(I.-*,-/,1-;:,-+81)1-'-,*)/'1-,-.'9,0/,-*,7').-.,-71,'5:7+1-,9-71'5:1+1-'-+1;:)('3-('56-7:<+-:9+-,/+7+-,-(+)-*)1,/+9,0/,-7+1+-+-)0B'19+J2'3-4+0C+0*'-/,97'>

Page 47: Analista de Sistema Operacional

������������ ������������������������������ !"�#���$�%&'����(�)���*!��#��+����"���'���,-�'(&�(�.�/��&����01�����!,���(�',��&������!,��(��2����"(&�(���#& ��&�-��&����%34 ����('���"�5$&#�'�(�"6��#�"(��*!��&� �"(&����'����(�"�"��,���$��&����$�',��#��+�&7'����$��8&���#�"����!,��(�".9:;<=��"��!(� �>&'���?����@"�-�'�,!�(��(�,-���2���,!,�#�'�#3'�&"�A&�� &"�&7�'(&"�-� ��"�!�,���(�'.�B�,���'��!'"�����/�&-��#��+�-����-�"�����34 &"����!,�A��(��-'3(��������#�'(���.�C&"(&�&-��&"�� ��&'���&''&"(34 &"�-� &"�7�'�&"��&�(� &�-&'&��7(�'���$�'��(�"�-�"�����&,��(�".D�/�&-�2�)(� �(&�(��-&'&�&���"('�7!�01����,��-&'&�&���,-&'&01�����A&�� &".���'��%�,- ���A�E!��!,&�-&'&�&��"*!�'�&���&��!('&��&���'��(&.�=,7&"�$��&'&,�&7�'(&"�����#��������E!& ,��(�����"-&0��-� &�(� &��-�',�(�����*!��#��+�&"�#�A&�&��,�",��(�,-�.

Page 48: Analista de Sistema Operacional

����������� �������������������������������������� �!�"�����������������#�$�������"�%�!����������������&'�������&��("�������!�����������������������!)�����"���������������'*�!��������������+������,��-���,�.��&�'���&�����#/��0������ 1��&��+�������.�!��&�������!�"��������!�����������������������!#�2�3��'�+������,��-�����������&!���!�!)�&�!��4��&'�)�&�'�����'*�����������'�%�56������'.���&!�.!��������!+��,����������! &���#78�"�!���������������������������'�.��������!��!��������������9��!�*)���&��+���������������(�����6���'*���&������������������&���������!+��,��#�:������!�;����������3�������!+��,�)���.����&!�&!������������<�=�>?���@�A��B�CDEFGHIJKJLDMNO)�&.���P)��!���56�������Q#���!���'�������6������!�������+������,��-���.�������6����,��������������.�!���)�&�!��"���'���!�����,����'�%�56�#�1���4���������.�!��������+�������!���'������������������&������!���,�����#R $!�.!����R $����'����:���!�'�R 8���������R S3����R 1!+��,��

Page 49: Analista de Sistema Operacional

�������������� ��������������������������������������������������������� !"#�$%$&'()*'+,-.'*/-,/012'3*4,'5*/)'6/6-621'7')52'3*()*/2'3210*'8,'0,024'8693,/:+*4;'<2=*/8,'2'>)9-2'3*4,'?6/8,@9'AB34,1*1'C'()*'7''2-6,/28,'2)0,5206-25*/0*'()2/8,'+,-.'/2+*D2'3*429'329029'8,'9*)'-,53)028,1'C'+,-.'*/-,/0121E')52'>)9-2'5269'2>12/D*/0*;A5'+*19F*9'2/0*16,1*9G'-,5,'/,'?6/8,@9'HIG'2/0*9'8*'9*'J2=*1')52'>)9-2'7'/*-*99E16,'2>161'2'J*1125*/02'8*'>)9-2;'K,'L*+*/G'31*-6925,9'23*/29'86D6021',9'0*15,9'/2'-26B2'8*'>)9-2G'()*'J6-2'/,'-2/0,'9)3*16,1'861*60,;

Page 50: Analista de Sistema Operacional

����������� ������������������������������������ !"!#�$%&'�())*+,-./0123.456.17.89:9;3.3.<9=9;3>56.<[email protected].?6<7.3?8923A.EFGHIJKL.?6A.7M7:?86L./0123AL.43.?31;3.:N19231L.;6<31.31.234>O71.<6.=D47A6.P62QB.RM91;7:.60;A61L.26:6.<3;3L.;3:34S6.7.;9?6B.T7?74<74<6.<[email protected].@62D.?A620A3L.?6<7:.7M91;9A.60;A31.283119V923>O71.<91?64W@791BX:3=947.U07.;6<6.3AU09@6.<7.;7M;6.17:.170.26:?0;3<6A.?61109.0:.30;[email protected];Z./01234<6.?6A.3AU09@61.<7.;7M;6L.?6<7.;7A.3.6?>56.<7.V98;A3A.?6A.30;6A71B[��\]�%&!�� !_� 56.a.0:3.;3A7V3.VZ298.?A6;7=7A.61.:391.46@61.<6.U07.@910389b3:.?6A.:796.<6.26:?0;3<6AB.c.d94<6e1.f.3g0<3.3.89:9;3A.6.U07.?6<7.17A.@910389b3<6.60.456Bh3A3.U07.7113.V042964389<3<7.V9U07.<[email protected]:?6A;34;7.U07.6.26:?0;3<6A.;74S3.0:3.264;3.<7.3<:9491;A3<6AL.?A6;7=9<3.?6A.174S3L.A7=91;A3<3B.-8a:.<9116L.6.010ZA96.U07.17.<717g3.A71;A94=9A.<7@7.;7A.103.?Ai?A93.264;3B

Page 51: Analista de Sistema Operacional

������������������ ������������������������������������ ��!��"#$��%�������� �&� ���������'������������������$(�������������������)*#+#,-��������������%����.�/��0������������������'�����������%�1%������ �����&� �2�����.�/�)�3���������������� �����&� �2��.����%� �%�����4�����/�%�)56#78�9:�":#+:9�9,;�����<�������� ���������������� ����������2��������������������%��=� ������)>���������?���������@AABCDEFG1�����<������%������������������������������0� �%�� ��������������/����������2��� �������0�����1�%��%��%�������%�'���4�� ����������������������������������)HIJKLMNOPIOMQRIS�� �������������� ������������������%����/���������/��������%������2�����T����?�)�U�����2�� �����&� ������%����%��'��V�%���������W��������������������������%����X����%�������V����&����� �%�������X)Y����������%�1%�1�Z���� ������ [���������/�����������'����� �%�������)�-����� '� �����������������������T����?������ ������/�����������)

Page 52: Analista de Sistema Operacional

�������������� ������������ ��������������������������� ���!"�#�$#��%�&�'�%�$��(�)�����!�*�$���!""��� �+�'�'��'��,�'��� ���!�*�$��!�'�"��*��-!��!��$���+-!.���#!�* ��'!$�/� ����0���"1!�'�""����������.���2��'!3"�4�*�$����� ����+���*�$"!��+�&�(1!�'��5#!��")�#!$�"���� ���"�! �$�"�!*(6�")�'��0��'!� ��������������"�#!�%!$�7,�+)��1!���*!$���"�� ��+�&�'!��!����������*$!%�""�!��+�! ��!�'!�/"��#!.8 ���"�!*(6�"�*�$��*�$"!��+�&�$�!�2��'!3"�4��"�1!����*79����'��:�$"!��+�&�(1!�)�� ��*!'��"�$��#�""�'��*!$� ��#+�� ��#!��!��!�1!�'�$���!����7$���'���$���+-!������"�9 �'�� ��#+�� �����:�$"!��+�&�$.;���*!$�������!��$�� ���+9 ��"�#!�%�9 $�(6�"�*!'���'��0�$�"� �#!�* ��'!$����"�+���!)��"*�#��+�������%���!"�'���$��"*�$<�#��.�=���0!��"�1!��+9 ��"�'�"�!*(6�"�'��*�$"!��+�&�(1!����"�����$�""����".��>���?!@#�.�2��'!3"�4�?��+�.

Page 53: Analista de Sistema Operacional

���������������� ������ �� ������ ��� ��� ������� ��������� ����� ������������ ��� ������ ����� �� ������� ��������� ���� �� !������ �����"��� �� #���#��� ����� �"��� #�� �� �"����$ %�� ��� ��������� ��� ��� ����� ��� ���� #�� ���& �������� �� ��'���� (�$ )����� �� ��� ��� ������ ��� *���� ���� ���� ������� ��� ��� ��������$+ ����� � � �����,������� �� ����� �� -./012-3452��� �6���� ����$ 7��� ������ ������� �� ��#�&����� ����� � ��������� #�� ��� 6��� �� ���,���� ���6 ���� ����$8��9:�+� ;,�"�"��"��< =6 ��� ���������� �� >����?� )����� ��� ���� �������� �� ����� �������$ +"��� ���� ����� ���� �� #���#��� ����� �� ���@���$ (����� ���� ���A�� ��� 6��� �� ���,���� ��� ��������� ��������� ����� ������ *���� B ���� ��� ��#���� �"���� B ��� �� �� "���� ���� ��������� B ���� ��� #�� ������ � �!�,��� �� C����������$ D��� � �������� �� ���6��� � #�� � ���� �����E��$� ��'���� ������� =6 ��� ��� ��"����� ��� �� ������ ������������ ���� ,��A�� ����� ���� ��FG�� �� ��������$

Page 54: Analista de Sistema Operacional

���������������� ������������������������������ ��!"�#�����$����$%&%'( ���$�%)( �#�$(��(��'��&%*+ (,-����)(#(���#��$����+�*��#�.���/%�$�0��1�$%����%2%3%4(�#��(�.�5+���+$(��'���%$� (6�3���#�����(���'#���* "&%'��.�'��������(�7%��$���( �$����'� ��89:��;�<=�>�3�( �?@���7�+�(�#�'��3�*%(�5+��&(4�(��&��#����( �'� ����(%��'3( (�����+(6���������%#� 8�A��( #%'+3( ���#���&�#%6���( (����%#� ���B�C.��(��#(�27��#���(3*+���&�%#������(�#%*�����$�3����D?�8�E�/%�$�0��1�$"��+�� #��(���#(�#�'��3�*%(F�GH%��I�@'�J�KLMNOPQRSRTLUVW.��*�XY�.�# ($+,Z������([8���D?��Z��������%#� ���$��#+2�8

Page 55: Analista de Sistema Operacional

���������������� ����������������������������������������� �!�������" �������!������#�������������$�%���&'� �������$���#�������������%� ����(�����(����!��(��)�*�����+���(������������������$���������(����(���!#�������������!�(����������� ��������������!�������(���,����(���%���������(�������!���(����)-./01234506.7*����(��������������������(�����+��!����(�����������!�(������������������������ �,�!���8��#�+����#������������+��������9��!���8��#�(���� �!����:��!#� ������!���#;�������������<������+������=�(������>?�����������!�(����)@��!�����������A����+������!���#;����9�����!�(8��#���������������������B�%���#���(������������������#�%�(�!��CD��!�(8��#���������������EF)GHI0.J75KL62.67M25J60.71I1D�����NOPQRSTUVQWOXW,�!���8��#�#����������(�<���������!�(�����!������(����#�%������������)����+������#�����!����$������#� ������!&'��,����(������%�����8��������(�)D�����(�������������� ���������!�(�����������������������E�!��������!��(�#;����<�������(���,�������������Y�����*#�Z���[�)�@�������A����+�����������(�9���������������������\?���#��� �������������������]���)

Page 56: Analista de Sistema Operacional

������������ ��������������������������������������������������������������������������������������������� ��������!����������"��#����������$%������������������#����� ������������&������������������!���'��������������"(�������������)&��&���)������* ��������������!����������"��#�'+�����������������,����������������������� ��������!����������"��#������������$%��������������������"��������-��������������.��,�/����*��������������������������'���������������#���������,!��������������+�����0���(����,��������������������,���%�����1����2�����������������������&���������,���������������������������$3������-������������,�������4��������������,��"������������ �������,������������"��������-�����'�5��������������������������������6�������������������/��������������������&����������������������,����������'���������"(�������������/��������������������������������1����2�'���������"(������������������������������������������������0������������7�������,��������"������8���������������1����2����������&��������������'�9���������� ��������!����������"��#����#��������������������������(��������&���������������&�����!����������"��#��0����������� �������������-��������"�����'����������������#����������&������������������������� ��������!����������"��#�����������7�"����������������$%������������������&���'�:��"(��������������������������$%����������������������&�����������$%����������������������0������,�����%�������/������������������������������������������*������������'����������������#�������,�����������������$3��������������1����2�'�

Page 57: Analista de Sistema Operacional

��������������������� ��������������������������������������������������������� ����������������������������������������������� !����������������������"���������������������������������������������������������#����������������� ���$%������������&�����������������������$'������������"�������������������#����(���������� ������������������������������������"�����������������������������������������!��������)�������������������"��������������������������������������"���������������*��+���������������,��������"����-������ ������������������������."�"���/�������������������#����'�����0��"���������������������#����������������������������� ���$%����������������������������$'��������������"����������������������������������������������(������1234567489:;<989:=��������������������������������������>����������������%���������������������������������������������'��������� ��������������#�������,����������������������#����'����������������%���*��+���&�*��+��?����$��������������#����'���"���������������������������������(���������*��+��?�������#������������'������������������"����������������������������@���A���BC�D������0�����������������������B����������������������������������������#����

Page 58: Analista de Sistema Operacional

�������������� ��������������������������������������������������������������������������������������������������������������������������������������������������� !�������������"����������������������������������������������#��������#��������������������������������������������������������������������������������������������� $%&'()*'+,-./-(,%')0-*/&)-12,*3,-%0'4*-5(0//467!�8����#�����#�����������"������������������#����������������"������������"������������#�������������������������!##�����99�

Page 59: Analista de Sistema Operacional

�������������� ��� ������������������������������ !���"���#��� �$�%��%�& �!����&�'�()�������������**+"��������,�$-� �$�%�&��������$��&"��&&���&�����$�$��� �������������'����. ���$/��������������**+01�#�!# !�������������&���� �� ��$2�&"��,����#�$���#�����$�%�&�����&"�'��,�����������&���3&��#�0�4�������'��,���������!����5�#6!# !�&���$6���&��������'2/�����6!,��������!��$�0�1��&���3&��#������� $27�&����#6!# !�&��6&�#�&0�8�������������#��$������# �&�����#�$%��&/����� $�����&�#�������'�&�'���������&0

Page 60: Analista de Sistema Operacional

��������������� ���������������������������

Page 61: Analista de Sistema Operacional

������������� ����� ����������� ������������ �� ������� ���������������������� ������������� �!����"���#��$�!"���������%��������&���� '���������������(���������)"�� �*��"����+���� ������(���� ������ �����%�,-��./0/./123�4�5.67/892�8.:; <��#� ��������=�>?+�&�@A(��'; B��C����&DB'����=�>E; <��#������F����#�����F����#���G���#�H�I,�����@�BE�������C����& ��������� ����'; J �������)"���������=K>E; G�GADLB; M�F������N"���

Page 62: Analista de Sistema Operacional

������������������������� ���������������������� ������������������������������������������������������������������� ������������������� !"#$%&�'()*�+)�,$,$-. /������������0�123�4�0����56��� 7. 8��9����4:�87����0�1;. <�������=����������������>����?��5�1;. /��������@>������������ ���������� ����A�����B���� C�D�����0E5�8;�������9����4�����F����� ����� �������G����H�����7. I����������BJBK:LG. M���N���������O� ���� �4������� ���� ����3��P�7QR"$S T$#',)'"+'UV'$�R !�W����F������A������>@������������ ����������G����H�X������������A=�������@�����������=��� ��������������<� �� �� �������>@���� ���3AK������������ ������� ����������=���� �����������������P���>����������������F�����=�� �����������G����H�J� ���� �������@��Y� ��A������������Z[\Z]_Z���� �����������������M�������A=������ ���3��G����H�C/��@��Y���@��A���3�������K�� ����������� �����������������I ���3���������@������� �����������C/����� �����@�@����� ���������� ���������� ����������=��� ���>������<� �� �� ���������������=���@��Y� �� ����3�������K�� �������

Page 63: Analista de Sistema Operacional

������������ ��������������������������������������������� ����!��"�����������#������$�#����������������%�����$���������&���'(��������#��&��������� ����!��)����������&��* � +,��� � �� � -��������$ � .��#/00!����!�1���������1���0#�2340!����!�"0.��#0�#&�����&2����2!����!�2�����2��2!����!�2"516������������������%����$���������7�����8��#���������.���������������#��#���������������������'8�����������������������1�9#������#���������#'8�$�����������2��������������������������#���:������������#��&�����$���%���������������)������������#������������7����"1;<=�����>���%���%�����������%�������������'8���8��#�����������������$����������'8�����#�����������������#'8���������7���1?���������$���������7����������:��@�#����������%����������A����������$��������������������������������B��$�#��������������������'(���������#����������8��#�������1�C���������������� ����!��"$����������������������#��&������%������D�.�����������������������������&���'(���#���8�1EF=FGHF<I�J���������������������������������������� ����!��"�������������������������������������#����K���$���%�������#�����������������1�L��������������%��������������8������&��.�����&����#�������������������1

Page 64: Analista de Sistema Operacional

�������������������� ����� ������� ������� ���������������� ���������������� ������������������� ���������������������� � ������������������� �������� !"#$%&'(')!*+,-����./0.-�����12�������345�6 ������-��������7�������8� ������������4�5����������2��������7����� ������������ �����-���9����:��;�������<����=�����>�������>������������������7����7���������34������-��� �� ��� �����2�-��� �8��?�������������������2�������� ������������������ ������?���������������������2�������>���-���������� �����2��=������ ��������2�����>������4@������������A��������� ����=�����>�����2�������� ��������2�����������>��������� ������4�@���������-��2��������������������7����=�-��� ��������<� ����������������7��������>7�����-�������������6�=��������� ����������������������� �7��������� �������� � ��������������� ����4����������������8���<���>������������������������ ���� � �����7�� ����������7������45������������� ������ ���������� ������������� ������-����� ����?�������������������������<�������������������7���� ���������������7�������7������ ����4BCDEFCGHIJHIJKJLMJDNC5����������2������ ���?�������������������-�6� ��7���� �����������������������7������� ��������� �����>������������4�O��� P���������������������������6 ����=��>��?����3������������������� ������7�� �1Q���������������������4

Page 65: Analista de Sistema Operacional

��������������� � ����������������������������������������������������������� !������������������"������������������#�����������������$%��&�����'(�)*+�+,-�.�/�������0001234567480348198:;���"�����<�=�������>����������������>??@���������/����������������"��� %���������������"��A�����B����/��C���������D�E��'�F���$�������������<G������������"��� !������<�=����������"�����������������H�<������E���%��I���������������'

Page 66: Analista de Sistema Operacional

��������� ��� ��������������������� ����������������������� ��� �����!����������"�� �

Page 67: Analista de Sistema Operacional

����������������� ���������������������������� �������������������� ������������������� ��������

Page 68: Analista de Sistema Operacional

������������������� ���������������������������� �����������

Page 69: Analista de Sistema Operacional

�������������� ������������������������������������ ��!��"��"��!�"�����#"���$�#��#�!!�����#���%��&'��()���*)������!#"���"��"���*�������#����� ��!�#���"*�+� ��"���#��������,*�"!����-��*��*��./'!"�*��"��-*!"01��2�#���!���1�$���"'*�!�"*!�+'�'�"�'��3+'45���,"*�������6��*"���!��"���!)�����&'�������"!"�"�#���!���1�$��"��������1����'��,"*��#��,�!�"��.7�*���8�#�"���&'������������%�9�����������9� 9"���!��' *"�������#���"!"01�$�#������*�$�,�&'��"���"��"���,"9�!)9� ���9�����*��"����!"#���" ��"�:�#!���,*.;<=>?@ABC<DEDFGH<IEJB<EKAEDFDLI@AEMNOPEQ@RK<SBETE=IAUAEDFR<BV�!���W"�!�$��"�X� �Y�#�� �4�"$�"�" ��"�&'��'�"��"���!��#��"���9"�*"4���������������������'�����*� �4��*��������Z!�"�&'���� ��!"�������������������!�4!"�"�$���!�#���"����"�#"�"#��"����"!"�����!�4!"�"�����'�����������*�.7 ������4�!��#�"��!�����������*�9���� ��*���'���!�4!"�"����"�" �������'������!�#'!����#�"�"���[���'!#��:"�"4�!.�7*!"9����� ��������\9� �9�!���*" �������'�������!�#���"��!$����"0�����]/������"!"!���'���4�!" �����!�4!"�"���� �#���"���.��Y��*���,��*����� ��X�_�Y�#�� �4�"��1��"#��*�#�'��'�*���*!"9"���*��$�&'"�������!�4!"�"��"!"����!�������!�"�*� "�,�#"��"���# "!"����1����������,"�!�����'�"�"01���������!�4!"�"$��"������'*!����!�4!"�"��#��*��'"��,'�#���"������!�" ���*�.�

Page 70: Analista de Sistema Operacional

������������������� �������������������������������������������������������������������������������������������������������� ��������������������� ��������� ������������������������������������������������������ ��������������������������������������� � !���������� � !���"#$%&'()*)+,-+$.+)-/0-+)12)%/)3+04#-#3+.5&)%/)6/0-+%&))7�����������8���� ������������������������������������9�� �� �:����;9<������� ��:=�������� ������������������ �����������������>��������� �� ������������������ ��������9?<�@���������� �����������������=������������9�����������������������������>��������������"#$%&'()*)A/6)-&6)6+#()+3,#-+4#A&()BC/)D+-#,#4+6)&)C(&8������������������ ������������������������������� �������������������������������E�F�=��G�������H����������I���J� �������K��������������������������������������������LM����M>M��� ���������� �����@���������������H���N����L�������������� ������������������7�������J����������������������������� ��������������������������������������J�������������������������������� �������������9������������ ������������������������ ������� �������O���� ����������������������

Page 71: Analista de Sistema Operacional

����������� ���� �� ������ ��������������������������� �� ������������� ������������������������� � !��"����#��$������%&���������'���� �����������()���� � !��*� �� �������� � ���������+�� ���� � !����'����,������"-�������������������.��� ���*����/� ��*��������� �������01&�()���� � !��*�� �#������ � ���������� �� �����#��'�����%&����"�2������������������ � !����� ����3�4��� � ������������� ��+�������������� �#,������� ���#���� ��/� �5'����� �� ���� �"-���������5'���������������������� � !�����3���� ��*�������6����*������/��� � ��������+��������� � �������*� � �������,3� ����� ������+����*�������� �� ��������������5'�"��������4�5'������,3� ���%7������5'�����#�������� �� ��'����3���� ������������������������ � !������+����� �������� ��+�� � � ���� � !��"

Page 72: Analista de Sistema Operacional

Os sistemas Unix sempre representaram uma opção importante quando se pretende fiabilidade e eficiência, embora existam muitas implementações especificas de determinados fabricantes (HP UX, IBM AIX, Digital ULTRIX, Digital UNIX, Novell UnixWare, SCO Unix, ...) todas elas mantêm um elevado grau de compatibilidade baseada no compilador de linguagem C, um conjunto de bibliotecas compativeis e um núcleo de sistema operativo (kernel) com conceitos que caracterizam os sistemas operativos tipo Unix.

Embora não exista compatibilidade binária entre os diversos sistemas tipo Unix, existe compatibilidade de código fonte, isto significa que o "software" desenvolvido em linguagem C para uma dada plataforma Unix pode ser "compilado" em qualquer outra plataforma Unix. Mais recentemente o projecto aberto Linux tem-se assumido como uma alternativa de enorme importância, com um núcleo desenvolvido de forma aberta ("open source"), encontra-se disponível de forma mais ou menos gratuita, através de diversas distribuíções. Estas distribuíções Linux, além do núcleo, incluem todo o "software" adicional e ficheiros necessários para o funcionamento do sistema, a maioria deste "software" adicional é também desenvolvido em "open source". Sem tomar qualquer partido, algumas das distribuições mais tradicionais são: Slackware, Redhat e Suse.

Administração de sistemas Linux

Dada a sua importancia actual, a maioria da informação constante neste documento baseia-se em Linux, contudo a administração de outros sistemas Unix não difere quase nada da administração de sistema Linux.

Com o seu carácter "open source", o sistema operativo Linux recebe as mais diversas contribuições e é actualmente a implementação Unix mais versátil, suportando as mais diversas possibilidades de configuração e integração. Administrar sistemas Linux pode ser um desafio significativo, normalmente os projectos "open source" produzem dois tipos de produto, "versão estável" e "versão em desenvolvimento/instavel", se o administrador se restringir à utilização das versões estáveis, tem certas garantias de uma existência pacífica, se pelo contrário tentar utilizar versões em desnvolvimento, corre riscos de instabilidade no respectivo sistema e possívelmente acabará a colaborar no desenvolvimento desses projectos.

Por uma questão de metodologia, a administração de um sistema operatvo pode ser dividida em várias áreas distintas:

• Administração de utilizadores - criar e modificar as definições relacionadas com os utilizadores do sistema: identificação interna; nome de utilizador; chave de acesso; grupos a que pertence; etc.

• Administração de sistemas de ficheiros - gerir o sistema de ficheiros, integrando diversos suportes físicos e gerir as permissões dos utilizadores sobre os ficheiros.

• Administração de "software" - gerir as aplicações disponíveis no sistema, a maioria das aplicações destinam-se aos utilizadores, mas por exemplo, podem também servir para a implementação de serviços.

Page 73: Analista de Sistema Operacional

• Administração de serviços - gerir serviços, com especial destaque para os serviços de rede.

Na realidade todas estas áreas estão intimamente relacionadas entre sí

Administração de utilizadores

Qualquer sistema multi-utilizador tem de manter uma base de dados de utilizadores, nesta base de dados, geralmente de tipo relacional, existe um registo para cada utilizador. Cada utilizador tem diversas propriedades associadas a sí, para gerir os utilizadores e todo o sistema em geral existe um "super-utilizador" ou administrador, nos sistemas Unix existe um único administrador que tem o nome "root" .

Nos sistemas tipo Unix os utilizadores estão definidos no ficheiro /etc/passwd, neste ficheiro de texto, cada linha corresponde a um utilizador, constando uma sequencia de campos, separados por dois pontos, todos os campos são obrigatórios, mas alguns podem estar vazios.

O exemplo seguinte ilustra um extracto de 8 linhas (8 utilizadores) de um ficheiro /etc/passwd:

root:BeDyr8qulmhZ2:0:0:root:/root:/bin/bash daemon:*:2:2:daemon:/sbin:/bin/bash bin:*:1:1:bin:/bin:/bin/bash postgres:*:26:2:Postgres Database Admin:/var/lib/pg sql:/bin/bash wwwrun:*:30:65534:Daemon user for apache:/tmp:/bin/ bash empress:*:35:2:Empress Database Admin:/usr/empress: /bin/bash guest:a28HqK3Yamh7t:1001:102:Utilizador nosso

convidado:/home/guest:/bin/csh user:uHr5fg6RtEw23:1002:102:Utilizador

local:/home/user:/bin/bash +

Os campos são, ordenadamente, os seguintes:

• "Login Name" ou "Username" - é o nome que o utilizador usa para se identificar perante o sistema, logo deve ser único no sistema.

• SALT+HASH(SALT+PASSWORD) - é o resultado da aplicação de uma função de "hash" à password do utilizador (em conjunto com o SALT que introduz um factor aleatório). É usado para autenticação do utilizador, para o efeito o utilizador fornece o seu "Username" e respectiva PASSWORD, o sistema calcula então HASH(SALT+PASSWORD) e verifica se coincide com o que está no ficheiro /etc/passwd. Neste campo, separados por virgulas podem ainda constar diversos valores referentes à validade da password, ver o ficheiro /etc/shadow.

• User Identifier (UID) - é um número inteiro usado para identificar o utilizador no interior do sistema, tal como o "Username" deve ser único, contudo ao contrário do "Username" que apenas consta no ficheiro /etc/passwd e é usado apenas para a identificação inicial perante o sistema, o UID é intensivamente usado nas operações internas pós-login. Como se pode observar o UID do utilizador "root" é zero, e deverá existir em todos os sistemas tipo Unix.

Page 74: Analista de Sistema Operacional

• Group Identifier (GID) - número inteiro que identifica o grupo primário a que o utilizador pertence, em Unix os grupos de utizadores estão definidos no ficheiro /etc/group, sendo que cada grupo possui um número de identificação único, o GID.

• Nome completo do utilizador • Localização do directório de trabalho - trata-se do nome do

directório de trabalho a atribuir após a entrada no sistema, tipicamente é um directório pessoal no qual apenas esse utilizador tem permissões, tem habitualmente a designação de HOME.

• Nome da shell inicial - quando o utilizador entra no sistema (depois da autenticação) o controlo da sessão tem de ser transferido para um programa que será executado já com as permissões desse utilizador, tipicamente é um programa interactivo interpretador de comandos em modo de texto, que tem a designação de "shell".

Grupos de utilizadores

A definição de grupos de utilizadores é muito vantajosa sob o ponto de vista de administração porque quando se pretende atribuir a muitos utilizadores um dado direito (permissão) é possível atribuir esse direito ao grupo, tendo como efeito que todos os utilizadores que são membros do grupo passam também a usufruir desse direito.

Nos sistemas Unix os grupos estão definidos no ficheiro /etc/group, este ficheiro tem uma estrutura semalhante à do /etc/passwd, os campos são os seguintes:

• O 1º campo define o nome do grupo, tal como para utilizadores este campo tem de ter um valor único.

• Normalmente não se usam passwords para grupos, por isso o 2º campo tem um "*" ou um "x".

• O 3º campo contém o GID, tal como acontecia no /etc/passwd para os UID, os GID tem de ser únicos no sistema.

• O 4º e último campo possui uma lista de utilizadores (separados por virgula) que pertencem ao grupo, isto apenas é necessário para os utilizadores que não têm o grupo mencionado como grupo primário no /etc/passwd.

A seguir apresenta-se um extracto de um ficheiro /etc/group:

root:x:0:root bin:x:1:root,bin,daemon daemon:x:2: users:x:102: nogroup:x:65534:root

Pode observar-se que apesar do grupo "users" não ter membros definidos, na realidade, por cruzamento com o exemplo /etc/passwd anterior, os utilizadores "guest" e "user" são membros.

Outro aspecto a destacar é a existência de um grupo chamado "root", se forem colocados utilizadores neste grupo, eles passarão a ter muitos dos direitos que o

Page 75: Analista de Sistema Operacional

administrador possui sobre objectos do sistema, já que este é o grupo primário do administrador.

Shadow passwd

Um dos problemas suscitados pelo ficheiro /etc/passwd é o facto de ter de ser legivel para todos os utilizadores. Uma vez que o HASH da password consta no ficheiro, torna-se possível tentar "adivinhar" uma "password" que gera esse HASH, possivelmente não será a mesma "password" que o utilizador usa, mas servirá como autenticação. Quebrar desta forma o mecanismo de autenticação é extremamente difícil e moroso, a abordagem que é usada na prática consiste em usar um programa gerador de "passwords", baseado por exemplo num dicionário e tentar essas "passwords".

Seja como for o acesso aos "hash" das "passwords" dos utilizadores é claramente um ponto fraco, o processo de tentativa de autenticação que deveria ser controlado pelo sistema (controlando o número máximo de tentativas e o atraso entre tentativas) pode ser simulado em outro sistema, basta para isso que o "hash" que consta no /etc/passwd seja copiado.

Para resolver este problema de segurança, existe a possibilidade de utilizar um ficheiro sombra para armazenar os hash das "passwords", este ficheiro é /etc/shadow, mas ao contrário do ficheiro /etc/passwd apenas é legivel pelo utilizador "root". A designação "shadow" (sombra) deve-se ao facto de conter exactamente os mesmos registos do /etc/passwd.

O ficheiro /etc/shadow tem uma estrutura semelhante ao /etc/passwd, mas os campos são os previstos para o campo da password no ficheiro /etc/passwd. Os campos, ordenadamente, são os seguintes:

• "Login Name" ou "Username" - é o nome que o utilizador exactamente igual ao que se encontra no ficheiro /etc/passwd.

• SALT+HASH(SALT+PASSWORD) - é o resultado da aplicação de uma função de "hash" à password do utilizador, tal como foi descrito para o ficheiro /etc/passwd, a respectiva entrada no ficheiro /etc/passwd passa agora a conter um "x".

• Data da última mudança de password - especificada em número de dias, desde 01/01/1970.

• Número de dias que faltam para o utilizador poder mudar a password.

• Número de dias que faltam para o utilizador ser obrigado a mudar a password (a password expira).

• Número de dias antes de ser obrigado a mudar a password em que o utilizador começa a ser avisado.

• Número de dias decorridos depois da a password expirar em que a conta é desactivada.

• Data em que a conta foi desactivada - especificada em número de dias, desde 01/01/1970.

• Campo não especificado, reservado para uso futuro.

Gestão das bases de dados de utilizadores Unix

Page 76: Analista de Sistema Operacional

Existem diversos programas que podem ser usados para gerir os utilizadores, aqui vou apenas referir os programas básicos, que devem estar disponíveis em todos os tipos de sistema Unix, existem depois muitos outros programas que usam os primeiros e que são especificos de cada sistema em particular, muitos deles com interface gráfica.

Na realidade para administrar utilizadores em Unix basta um editor de texto, de preferência o "vi", o único campo que não pode ser editado directamente é o "hash" da password, para isso é necessário recorrer ao programa "passwd".

Em sistemas onde se usa "shadow passwords", depois de modificar manualmente o /etc/passwd é necessário ainda invocar o programa "pwconv". O "pwconv" cria no directório corrente um ficheiro "npasswd" e um "nshadow" que correspondem às novas versões dos ficheiros /etc/passwd e /etc/shadow depois de realizada a junção da informação.

Os utilizadores podem alterar alguns aspectos da sua conta, o administrador pode alterar qualquer conta, para o efeito os programas seguintes verificam se quem os está a executar é o administrador ou não:

• passwd - permite alterar a password do utilizador, permite ainda ao administrador gerir os parâmetros suplementares do ficheiro /etc/shadow.

• chfn ("Change full-name") - permite alterar o nome completo do utilizador.

• chsh ("Change shell") - permite alterar o programa inicial do utilizador.

Geralmente todos os sistemas dispõem de programas mais sofisticados para manipular utlizadores, a utilização destes programas está geralmente reservada ao administrador:

• useradd - permite adicionar novos utilizadores, procura automáticamente um UID não usado e cria a "home directory", os utilizadores são criados segundo um "template", ou especificando as diversas caracteristicas na linha de comando.

• userdel - permite remover um utilizador e pode também remover a "home directory".

• usermod - permite alterar qualquer dado relacionado com um utilizador, incluindo o "username" e mesmo o UID, bem como grupos a que pertence.

• groupadd - criação de novos grupos de utilizadores. • groupmod - modificação de grupos de utilizadores (nome do

grupo e GID). • groupdel - eliminação de grupos de utilizadores.

A utilização de programas especificos é mais razoável do que a edição manual, estes programas especificos garante a exclusão mútua para escrita, isto é garantem que nunca existem dois programas a alterar simultaneamente as bases de dados dos utilizadores, com os resultados imprevisiveis que daí podem resultar, por outro lado a edição manual pode, por erro do administrador levar a que os ficheiros não respeitem a

Page 77: Analista de Sistema Operacional

formatação ou não sejam coerentes. Tratando-se da base de dados dos utilizadores estes erros podem ser muito graves.

Bases de dados de utilizadores centralizadas - NIS

Com a rápida evoluçãao das redes de computadores, em grande parte impulsionadas pelos sistemas operativos Unix, tornou-se absolutamente necessário criar sistemas centralizados para estas bases de dados que evitassem uma gestão independente para cada máquina de uma rede, o mais tradicional em ambiente Unix é o sistema conhecido por "Yellow Pages" (yp) ou NIS ("Network Information Service").

Este sistema é composto por um servidor "ypserv", instalado numa máquina central por clientes "ypbind" instalados nas outras máquinas. Os vários clientes (ypbind) contactam o servidor para obterem mapas, que não são mais do que equivalentes dos conteúdos habituais dos ficheiros /etc/passwd, /etc/group e outros, como por exemplo o /etc/hosts ou o /etc/services.

O servidor (ypserv) não usa directamente os ficheiros locais para responder aos clientes, existem programas (geralmente invocados através do comando "make" no directório /var/yp) que convertem a informação residente nos ficheiros locais (aqui vistos como ficheiros fonte) para um formato adequado ao servidor.

Os ficheiros fonte podem ou não ser as versões em uso local no servidor (localizadas no directório /etc), se forem usadas como fonte as versões locais existe a grande vantagem de poderem ser usados os programas de gestão de utilizadores atrás referidos, apenas é necessário não esquecer de, após as alterações, invocar o comando "make" no directório /var/yp para actualizar a base de dados NIS. A desvantagem desta opção é que os utilizadores de sistema, tais como root, daemon, field, ... também vão ser colocados na base de dados.

A opção por ficheiros separados como fonte NIS (noutro directório que não /etc) implica a necessidade de se usar programas especificos para gestão de utilizadores que permitam a manipulação dos ficheiros noutros directórios, estes programas não abundam.

Os clientes NIS utilizam o programa ypbind direccionado para o servidor NIS, para que na autenticação dos utilizadores o servidor NIS seja consultado é necessário que a última linha dos ficheiros locais (/etc/passwd, /etc/group e /etc/shadow) contenha o sinal "+", que significa adicionar toda a informação do servidor NIS (também é possivel adicionar utilizadores NIS individuais, usando linhas contendo "+username". Nos clientes NIS é ainda possível usar vários comandos tais como o "ypcat" para consultar os vários mapas disponibilizados pelo servidor NIS, ou o "ypmatch" para pesquisar os mapas.

O servidor NIS (ypserv) é apenas de leitura, para que os utilizadores possam alterar os seus dados "password/shell/nome-completo" recorre-se a um serviço separado, assim conjuntamente como o "ypserv" instala-se um outro servidor, o "yppasswdd" no lado do cliente NIS utiliza-se agora os comandos yppasswd, ypchsh e ypchfn que contactam o yppasswdd no servidor NIS.

Page 78: Analista de Sistema Operacional

Suporte a multiplas origens de dados - nsswitch

Com a introdução do NIS passaram a existir nos clientes duas origens para as definições de utilizadores, as bases de dados locais (no directório /etc) e as bases de dados NIS.

A forma como se sinaliza tal facto é através da colocação de sinais "+" nas versões locais, tal significa que naquele ponto da pesquisa local deve ser realizada uma pesquisa no servidor NIS.

Para o caso da resolução de nomes de máquinas podemos ter mesmo 3 origens diferentes para os dados: local (/etc/hosts), NIS ou DNS, os sistemas que são usados e em que ordem estão especificados no ficheiro /etc/host.conf.

Os sistema Linux mais recentes expandem significativamente esta ideia, generalizando o suporte a multiplas origens para a informação de sistema, nomeadamente quanto a utilizadores. O sistema NSS ("Name Service Switch"), usa a informação constante no ficheiro /etc/nsswitch.conf para definir para cada tipo de informação, quais as origens a pesquisar e em que ordem.

O NSS permite distinguir os seguintes tipos de informação de sistema: aliases, ethers, group, hosts, netgroup, network, passwd, protocols, publickey, rpc, services e shadow. Para cada um dos tipos de informação podem ser definidas as origens a pesquisar e a ordem que são pesquisadas.

As origens possíveis para a pesquisa são definidas de forma modular, para cada tipo de origem deve ser instalada a biblioteca apropriada, geralmente com designação do tipo libnss_SERVICE.so, onde SERVICE é substituido pela designação do tipo de base da dados que pode posteriormente ser usada no /etc/nsswitch.conf. Alguns exemplos são:

• libnss_files.so - bases de dados locais (/etc) • libnss_compat.so - bases de dados locais ou NIS (compatibilidade

com sistemas anteriores) • libnss_nis.so - servidores NIS • libnss_dns.so - servidores DNS • libnss_ldap.so - servidores LDAP (X.500) • libnss_winbind.so - servidores Microsoft (NT/2000) - Samba

suite

O NSS permite um acesso transparente a diversas fontes de informação de sistema, contudo quando se trata de informaçãao referente a autenticação tudo se complica, no caso do NIS, as passwords são armazenadas exactamente da mesma forma que nas versões locais, mas se queremos generalizar para outros tipos de bases de dados de sistema, certamente que vai ser necessário suportar outros formatos. Recorde-se que mesmo para o NIS foi necessário criar um serviço separado (yppasswdd) para permitir a alteração de passwords.

Para resolver o problema da autenticação com diversos tipos de bases de dados foi criado o conceito de "Pluggable Authentication Module" (PAM), trata-se de um

Page 79: Analista de Sistema Operacional

sistema modular que por adição das bibliotecas apropriadas, geralmente residentes no directório /lib/security, permite aos programas usar os diversos sistemas de autenticação. Os ficheiros de configuração residentes no directório /etc/pam.d/ permitem definir para cada aplicação quais os modulos de autenticação a usar, tais como pam_ldap, pam_winbind, etc.

Administração de sistemas de ficheiros

O sistema operativo Unix utiliza uma árvore de directórios única, isto é, no acesso aos ficheiros não existe o conceito de dispositivo de armazenamento (ex.: letras de drive), todos os dispositivos de armazenamemnto são integrados numa única árvore de directórios.

Apesar disso são suportados um grande número de diferentes tipos de sistemas de ficheiros residentes nos mais diversos tipos de dispositivo de armazenamento ou servidores de ficheiros, que são depois integrados numa mesma árvore de directórios.

A operação de integração de sistemas de ficheiros residentes em dispositivos distintos é conseguida à custa do conceito de "montagem".

O sistema de ficheiros integrado começa a ser constituido através da montagem do directório RAIZ, simbolizado por "/", este é sempre o primeiro passo, geralmente o dispositivo que é usado para este efeito é um disco local, mas para máquinas "diskless" também pode ser um directório residente num servidor de ficheiros, ou um disco de RAM.

Uma vez montada a raiz (/) podem ser acrescentados é estrutura outros sistemas de ficheiros residentes em outros dispositivos ou servidores de rede, para o efeito basta que na estrutura que já está montada exista um directório vazio, a montagem consiste na associação do directorio vazio ao dispositivo em questão. Depois de realizada a montagem o ponto inicial do sistema de ficheiros residente no dispositivo/servidor passa a coincidir com o que antes era o directório vazio, isto é o directório deixa de estár vazio e passa a conter a informação que se encontra no dispositivo/servidor.

As montagens são permanentes até que sejam "desfeitas" (desmontagem), ficando disponíveis para todos os utilizadores e aplicações do sistema, estas operações apenas podem ser realizadas pelo administrador (root).

O comando "mount" permite, montar um sistema de ficheiros, a sua sintaxe básica é a seguinte:

mount dispositivo ponto-de-montagem

A especificação do dispositivo varia de acordo com o seu tipo, os dispositivos locais estão definidos no directório /dev, por exemplo numa máquina equipada com dois controladores IDE, os discos serão:

• /dev/hda - disco MASTER do controlador 1 (ou primário) • /dev/hdb - disco SLAVE do controlador 1 (ou primário) • /dev/hdc - disco MASTER do controlador 2 (ou secundário)

Page 80: Analista de Sistema Operacional

• /dev/hdd - disco SLAVE do controlador 2 (ou secundário)

A maioria das formatações para os discos exige a definição de partições, mesmo que seja uma única que ocupa todo o disco, as partições sõo identificadas por números inteiros que se acrescentam é identificação do disco, a primeira partição é a 1, a segunda a 2 e assim sucessivamente, deste modo, por exemplo a terceira partição do disco MASTER do controlador secundário é identificada por /dev/hdc3.

Para o caso de controladores de discos SCSI, que ao contrários dos controladores IDE não estão limitados a dois discos, as identificações dos discos são /dev/sda, /dev/sdb, /dev/sdc, ... . Novamente, caso existam partições nos discos, estas serão númeradas e identificadas da mesma forma que foi descrita para os discos IDE. Os drives de disquete são identificados por /dev/fd(n), onde (n) é substituido por um número, o equivalente ao drive A: é /dev/fd0, o drive B: será /dev/fd1.

O comando mount sem argumentos devolve uma listagem das montagens correntes, esta informação é mantida no ficheiro /etc/mtab, o exemplo seguinte mostra um resultado da invocação do comando mount, sem argumentos.

/dev/hda3 on / type ext2 (rw) proc on /proc type proc (rw) /dev/hda1 on /boot type ext2 (rw) /dev/hdb on /cdrom1 type iso9660 (ro) /dev/hdc1 on /usr/local2 type ext2 (rw) /dev/fd0 on /disquete type msdos (ro) //winbox/c on /mnt/doshdd type smbfs (0) linuxbox:/usr on /usr2 type nfs (rw,addr=192.168.0. 2)

A informação apresentada consiste na identificação do dispositivo, ponto de montagem, tipo de sistema de ficheiros e opções de montagem, por exemplo rw=leitura/escrita e ro=leitura-apenas.

Podemos verificar que a raiz do sistema de ficheiros é a terceira partição do disco MASTER do controlador IDE primário, enquanto a primeira partição do mesmo disco se encontra acessivel no directório /boot.

O nome "proc" não corresponde a nenhum dispositivo, é usado pelo núcleo do sistema operativo para guardar diversa informação sobre o seu estado e deve estár sempre montado no directório /proc.

De destacar ainda o /dev/hdb montado no directório /cdrom1, não se trata de um disco, mas sim de um leitor de CD-ROM, o facto de os CD's não terem partições justifica o facto de não existir qualquer numeração na identificação do dispositivo, o tipo de sistema de ficheiros mais comum para os CD-ROM's é o ISO9660, note-se ainda que esta montagem é apenas de leitura (ro). Pode também observar-se que a disquete correspondente ao drive A: está montada no directório /disquete.

As duas últimas linhas apresentadas correspondem a directórios de servidores de rede, nestes casos a forma de definir o dispositivo depende do tipo de servidor, no caso, //winbox/c corresponde a uma partilha com o nome "C", por um PC Windows/98, chamado "WINBOX", o protocolo usado é o SMB (tipo de sistema de ficheiros é "smbfs"), este sistema de ficheiros remoto fica acessível no directório /mnt/doshdd. A

Page 81: Analista de Sistema Operacional

última linha corresponde à montagem do directório /usr, exportado por uma máquina chamada "LINUXBOX", usando o protocolo NFS, este sistema de ficheiros remoto fica acessível em /usr2.

O sistema operativo Unix usa intensivamente "caching" nos acessos aos sistemas de ficheiros que estão montados, para termos a certeza de que todas as alterações sobre um sistema de ficheiros são colocadas no dispositivo, este tem de ser desmontado. Para desmontar um sistema de ficheiros usa-se o comando "umount" que recebe como argumento o nome do directório onde o dispositivo está montado. Isto é valido por exemplo para dispositivos amoviveis, especialmente se montados no modo "leitura-escrita", por exemplo para usar uma disquete temos de realizar as operações na seguinte ordem: COLOCAR DISQUETE - MONTAR DISPOSITIVO - UTILIZAR - DESMONTAR DISPOSITIVO - RETIRAR DISQUETE.

Em fases iniciais de desenvolvimento do suporte de alguns tipos de dispositivo, em especial para dispositivos correspondentes a servidores de ficheiros, pode ser necessário recorrer a programas separados para realizar as operações de montagem, posteriormente esse suporte é integrado no sistema e pode ser usado o comando mount. O ficheiro /proc/filesystems contém a lista de tipos de sistemas de ficheiros suportados pelo núcleo do sistema operativo e que por isso podem ser montados com o comando "mount".

Embora os sistemas mais recentes já possuam o suporte de "smbfs" (acesso a servidores MicroSoft) integrado, podendo ser usado o comando mount, em sistemas Linux mais antigos, ou em que o suporte de "smbfs" não foi incluido ao compilar o núcleo do sistema operativo, pode ser necessário usar o comando smbmount. Embora não exemplificado acima, outro tipo de servidor suportado são os servidores Novell Netware, sendo nesse caso o tipo de sistema de ficheiros ncpfs, também neste caso, em versões mais antigas do Linux pode ser necessário recorrer ao programa "ncpmount" . Embora existam também equivalentes smbumount e ncpumount, o comando umount permite desmontar qualquer tipo de sistemas de ficheiros.

Quando se realiza uma montagem, com recurso ao comando mount, podemos especificar o tipo de sistema de ficheiros, usando a sintaxe mount [-t tipo-fs] dispositivo directório-de-montagem, se o tipo é omitido o comando tenta "adivinhar", para isso pode recorrer à forma como "dispositivo" está especificado, ou simplesmente tentar ler do dispositivo essa informação.

Alguns tipos vulgarmente suportados em Linix são:

• minix - primeiro sistema para o Linux, ainda é usado para disquetes e discos de RAM. • ext - versão melhorada do minix, que foi actualmente substituida pelo ext2. • ext2 - versão actualmente usada na maioria dos sistemas Linux. • hpfs - usado pelo OS/2, em linux apenas é possível o acesso de leitura. • msdos - usado pelo MS-DOS e Windows 3.xx. • umsdos - sistema com suporte dos atributos necessários ao Unix, implementada sobre uma

formatação msdos. • vfat - msdos com suporte de nomes longos, usada pelo Windows/95/98. • proc - sistema interno, usado como interface com o núcleo do sistema operativo. • nfs - acesso por rede a servidores NFS.

Page 82: Analista de Sistema Operacional

• iso9660 - usado pelos CD-ROM. • smbfs - acesso por rede a servidores SMB (Samba; Windows/95/98; Windows NT; Windows

2000; ...) • ncpfs - acesso por rede a servidores NCP (Novell; ...) • affs- acesso por rede a servidores AMIGA. • sysv - usado por outros sistemas operativos tipo Unix.

Durante o arranque ("boot") de um sistema Unix existe um conjunto de dispositivos que deve ser "montado" no sistema de ficheiros automaticamente. O ficheiro /etc/fstab contém a lista de todos os dispositivos que devem ser montados no arranque da máquina (e devem ser desmontados no encerramento da mesma). Eis um exemplo:

/dev/hda3 / ext2 defa ults 1 1 /dev/hda2 swap swap defa ults 0 0 /dev/hda1 /boot ext2 defa ults 1 2 /dev/hdb /cdrom1 iso9660 ro 0 0 /dev/hdc1 /usr/local2 ext2 defa ults 1 1 none /proc proc defa ults 0 0

A partição /dev/hda2 é usada para SWAP (memória virtual), sendo formatada de forma apropriada para esse efeito. Embora para as partições de SWAP não exista o conceito de montagem porque essas partições não são directamente acessiveis, nem fazem parte do sistema de ficheiros, devem ser activadas durante o arranque e para isso são registadas no ficheiro /etc/fstab.

Os sistemas de ficheiros em Unix, para serem completamente funcionais, necessitam de um conjunto de caracteristicas importantes em termos de caracterização de cada entrada existente (ficheiro, directório, ... ). Estas caracteristicas (atributos) que devem estár associadas a cada entrada (i-node), algumas das mais importantes e visíveis são:

• Nomes com até 255 caracteres c/ suporte de qualquer caractere e distinção maiusculas/minusculas.

• MODO, permissões/flags (16 bits) • UID, identificação do propriétário (16 bits) • GID, identificação do grupo (16 bits) • ATIME, data/hora do último acesso (32 bits) • CTIME, data/hora em que foi criado (32 bits) • MTIME, data/hora da última modificação (32 bits)

Nem todos os sistemas de ficheiros suportados pelo Linux obdecem a estas caracteriscas, sendo nessas situaçãoes realizadas adaptações de modo a que as diferenças que transpareçam sejam minimas, por exemplo se o sistema de ficheiros não suporta permissões ou outras propriedades, estes atributos serão definidos de um modo fixo no acto de montagem e o sistema montado aparenta ter esses atributos.

Cada entrada num sistema de ficheiros Unix possui associada a sí uma identificação de utilizador (UID) e uma identificação de grupo (GID). Quando um utilizador cria uma nova entrada (ex.: ficheiro) o UID desse utilizador fica associado ao

Page 83: Analista de Sistema Operacional

ficheiro, bem como o GID do grupo primário desse utilizador. O UID associado a uma entrada indica quem é o proprietário do ficheiro.

Cada entrada num sistema de ficheiros Unix deve suportar o atributo MODO com capacidade para 16 bits, do bit mais significativo para o menos significativo, eles são usados da seguinte forma:

• 4 bits usados pelo sistema para definir o tipo de entrada no sistema de ficheiros. Em linux, adoptando a notação decimal os valores usados são:

o 1 - FIFO (PIPE) o 2 - DEVICE (char) o 4 - Directório o 6 - DEVICE (block) o 8 - Ficheiro o 10 - Ligação Simbólica o 12 - Socket

Estes quatro bits são manuseados apenas pelo sistema operativo.

• SETUID - Alteração do UID para ficheiros executáveis. • SETGID - Alteração do GID para ficheiros executáveis. • STICKY - Utilização especial, depende do tipo de entrada e do

tipo de sistema.

• OWNER READ PERMISSION - Acesso de leitura para o proprietário.

• OWNER WRITE PERMISSION - Acesso de escrita para o proprietário.

• OWNER EXECUTE PERMISSION - Autorização de execução para o proprietário.

• GROUP READ PERMISSION - Acesso de leitura para os membros do grupo.

• GROUP WRITE PERMISSION - Acesso de escrita para os membros do grupo.

• GROUP EXECUTE PERMISSION - Autorização de execução para os membros do grupo.

Page 84: Analista de Sistema Operacional

• OTHERS READ PERMISSION - Acesso de leitura para todos os utilizadores.

• OTHERS WRITE PERMISSION - Acesso de escrita para todos os utilizadores.

• OTHERS EXECUTE PERMISSION - Autorização de execução para todos os utilizadores.

Como foi referido os 4 bits mais significativos são reservados para o sistema e nunca são manuseados directamente, os 3 bits seguintes definem permissões especiais que se abordará mais tarde, seguem-se 3 grupos de 3 bits que definem as permissões para 3 entidades, respectivamente o proprietário da entrada (UID), o grupo associado à entrada (GID) e todos os utilizadores.

Como se pode observar existem 3 direitos básicos (permissões) LEITURA, ESCRITA e EXECUÇÃO. O significado que estas permissões assumem dependem do tipo de entrada, para os dois tipos mais comuns de entrada no sistema de ficheiros, o significado é o seguinte:

• FICHEIROS / LEITURA - permite vizualizar o conteudo do ficheiro.

• FICHEIROS / ESCRITA - permite alterar o conteudo do ficheiro. • FICHEIROS / EXECUÇÃO - permite executar o ficheiro, isto é

interpretar o seu conteúdo com sendo executável e criar um processo correspondente.

• DIRECTÓRIOS / LEITURA - permite vizualizar o conteudo do directório (entradas).

• DIRECTÓRIOS / ESCRITA - permite alterar o conteudo do directório (entradas). Por exemplo remover ficheiros ou alterar o respectivo nome.

• DIRECTÓRIOS / EXECUÇÃO - permite tornar o directório o directório corrente/de trabalho.

Para manter a segurança eficaz existem ainda as seguintes restrições:

• Apenas o proprietário (ou root) pode alterar as permissões. • Apenas o administrador (root) pode alterar o proprietário. • Apenas o proprietário pode alterar o grupo, mas só se pertencer a

esse novo grupo.

As permissões básicas READ/WRITE/EXECUTE são habitualmente representadas através de um digito que correspondem à representação decimal dos 3 bits, deste modo EXECUTE corresponde ao valor 1 (1º bit), WRITE corresponde ao valor 2 (2º bit) e READ corresponde ao valor 4 (3º bit).

Exemplos: 7 representa todos os bits com valor 1, ou seja todas as permissõ:es; 4 representa permissão de leitura apenas; 5 representa permissão de execução e de leitura.

Page 85: Analista de Sistema Operacional

Representando na forma decimal os 3 grupos de permissões, para proprietário, grupo e outros forma-se uma sequencia de 3 digitos. Exemplos:

• 644 - READ e WRITE para o proprietário, READ para o grupo e READ para outros.

• 750 - READ, WRITE e EXECUTE para o proprietário, READ e EXECUTE para o grupo e nenhuma permissão para os outros.

Este tipo de representação é vulgarmente usado no comando "chmod" que permite alterar as permissões sobre uma entrada do sistema de ficheiros.

A permissões podem facilmente ser visualizadas através do comando "ls" com output longo (ls -l), eis um exemplo de uma listagem deste tipo de um directório /etc:

total 1318 -rw-r--r-- 1 root root 9 Dec 10 1 999 HOSTNAME drwxr-xr-x 2 root root 1024 Mar 10 2 001

SuSEconfig -rw-r--r-- 1 root root 40458 Oct 9 18 :50

TextConfig lrwxrwxrwx 1 root root 23 Oct 14 01 :23 X ->

/usr/local/deix/SVGA_16 -r--r--r-- 1 root root 12758 Jan 28 2 000

apsfilterrc -rw------- 1 root root 608 Nov 14 09 :41 crontab drwxr-xr-x 2 root root 1024 Oct 9 1 999 default -rwxr-xr-x 1 root root 106 Sep 22 2 000 hostOff -rw-r--r-- 1 root root 3139 Sep 22 2 000

hostOff.log -rw-r--r-- 1 root root 10137 Nov 16 15 :52 hosts -rw------- 1 root root 457 Jul 27 00 :04 lilo.conf lrwxrwxrwx 1 root root 28 Mar 14 2 001

lmhosts.rpmorig -> /usr/local/samba/lib/lmhosts -rw-rw-r-- 1 root root 32768 Oct 9 1 999 psdevtab -rw-r----- 1 root shadow 879 Oct 19 11 :31 shadow- -rw------- 1 root root 340 Oct 20 12 :07 ypgroup -rw-r--r-- 1 root root 107 Oct 8 1 998 ytalkrc lrwxrwxrwx 1 root root 7 Oct 9 1 999 zshrc ->

profile

Na coluna da esquerda são representas as permissões/modo, primeira letra indica o tipo de entrada:

• (-) Ficheiro Normal • (d) Directório • (l) Ligação simbólica • (c) Device (char) • (b) Device (block) • (p) FIFO (pipe) • (s) Socket

As 9 letras seguintes representam as permissões para proprietário, grupo e outros (3 letras para cada).

Page 86: Analista de Sistema Operacional

Quando um utilizador cria um ficheiro ou directório, as permissões com que este é criado são definidas através da FILE CREATION MASK , esta máscara está definida no formato décimal acima descrito, nesta máscara devem estar activos os bits que se pretende forçar a zero nos novos ficheiros e directórios.

Os utilizadores podem alterar a sua mascara de criação de ficheiros, geralmente o valor inicial (definido pelo sistema) é 022, que significa não dar permissão de escrita para o grupo nem para os outros. O valor desta máscara pode ser alterado usando o comando "umask". Alguns sistema Unix podem guardar mascaras individuais para cada utilizador (usando o campo de comentários do /etc/passwd), a maioria dos sistema Linux não o faz e por isso as alterações da mascara têm efeito apenas durante a sessão.

Quando um utilizador possui direitos de execução sobre um ficheiro, tal significa que se trata de um programa que pode ser transformado num processo em execução. Quando um utilizador transforma um destes ficheiros num processo (invoca o executável) o processo possui sobre o sistema as mesmas permissões do utilizador que o invocou, isso acontece porque os processos ficam com um UID/GID associado correspondentes ao utilizador que os cria.

Em muitas situações torna-se conveniente dar aos utilizadores permissões especiais, mas apenas para executar determinadas tarefas bem definidas que não comprometam a segurança. Para o conseguir, em Unix, é possível associar a um ficheiro executável o modo SETUID ou SETGID, se o ficheiro executável possúi um destes modos, o processo fica autorizado a alterar respectivamente o seu UID ou GID para os correspondentes aos do ficheiro. Observe-se os exemplos seguintes:

-rwsr-xr-x 1 root shadow 34936 Sep 12 1 998 /usr/bin/passwd

-r-sr-sr-x 1 root root 20704 Sep 12 1 998 /usr/bin/lpr

Podemos observar que o programa /usr/bin/passwd tem activo o modo "s" nas permissões de proprietário, logo tem a possibilidade de adquirir o UID de root, e as suas permissões, diz-se que é um programa SETUID ROOT. Na segunda linha está listado o programa /usr/bin/lpr que é SETUID ROOT e SETGID ROOT.

Os programas SETUID devem ser vistos sempre com desconfiança pois permitem a um utilizador qualquer adquirir as permissões do proprietário. Estas permissões especiais apenas devem ser associadas a programas de inteira confiança e muito bem testados, se eventualmente um utilizador conseguir alterar o comportamento normal de um destes programas as consequencias podem ser extremamente graves. Como medida de segurança adicional, em alguns sistemas, os bits SETUID e SETGID podem ser automaticamente desactivados sempre que se realiza uma operação de escrita sobre o ficheiro.

Finalmente falta referir a utilização do bit STICKY (representado pela letra "t"), este bit pode ter diferentes significados em diferentes sistemas Unix, por exemplo para directórios o significado mais habitual é impedir a remoção de entradas a outros utilizadores além do proprietário dessas entradas, neste contexto é habitual estár associado aos directórios temporários partilhados, nos quais se pretende que todos os

Page 87: Analista de Sistema Operacional

utilizadores possam criar novas entradas, mas não se pretende que uns possam remover/alterar as entradas dos outros:

drwxrwxrwt 5 root root 5120 Nov 19 00 :01 tmp

Recorde-se que o direito de remover/mover entradas num sistema de ficheiros Unix, não é ditado pelas permissões sobre essas entradas, mas sim pelas permissões sobre o directório onde as entradas se encontram.

Uma outra utilização comum do STICKY bit é em ficheiros executáveis, para evitar que fiquem bloqueados quando existem processos respectivos em execução, se o STICKY bit está activo, o ficheiro binário é colocado no dispositivo de SWAP para ser usado de forma privada pelo processo em execução. Em alguns sistema apenas o administrador pode activar o STICKY bit.

Ligações Simbólicas

De entre os vários tipos de entrada num sistema de ficheiros Unix vulgarmente manuseados directamente pelos utilizadores, além dos ficheiros e directórios, destacam-se ainda as ligações simbólicas. As ligações simbólicas são um conceito simples, mas com enorme utilizade para os utilizadores em geral e muito em especial para o administrador. Trata-se de entradas no sistema de ficheiros que apontam para outra entrada noutro ponto do sistema de ficheiros.

Na listagem exemplo do directório /etc anteriormente apresentada podem observar-se 3 ligações simbólicas. Para todos os efeitos as propriedadas de uma ligação simbólica são as propriedades do "apontado", tipo de entrada (ficheiro, directório, etc), modo (permissões, etc), UID/GID. A única diferença entre o apontador (ligação simbólica) e o apontado está no nome, que pode ou não ser igual, e na localização.

Para criar uma ligação simbólica pode ser usado o comando:

ln -s {apontado(entrada já existente)} {apontador(ligação simbólica a criar)}

As utilizações são as mais diversas. De um modo geral as ligações simbólicas são úteis sempre que pretendemos que algo aparente existir onde não existe ou/e que algo aparente ter um nome que não tem.

Administração de "Software"

A instalação de "software" num sistema Unix pode ser realizada por diversas vias, uma das caracteristicas importantes deste tipo de sistema é a possibilidade de as actividades da administraçõo seram realizadas a diversos níveis de acordo com as necessidades particulares e nível de conhecimento do administrador sobre os detalhes de funcionamento considerados de baixo nível.

Gestores de aplicações instaladas

Page 88: Analista de Sistema Operacional

Com o progressivo desenvolvimento do sistema operativo Linux começam a ser cada vez mais comum "software" de gestão de aplicações instaladas. Estes programas de gestão do "software" instalado mantêm uma base de dados onde são registados todos os programas que estão instalados no sistema, os ficheiros pelos quais cada um dos programas é composto e ainda as relações de dependendecia entre o diverso "software".

A sua utilização é extremamente vantajosa e simplifica de forma muito significativa o trabalho do administrador. Remover, actualizar e instalar "software" torna-se muito mais simples. A instalação de um dado "software" com estes sistemas exige desde logo a obtenção de um ficheiro de instalação do "software" apropriado ao gestor em uso. Estes ficheiros de instalação (normalmente designados por "packages"), além dos ficheiros pelos quais é constituida a aplicação, contêm diversa informação quanto a pré-requesitos a serem verificados, tais como o tipo de plataforma exigido e as dependencias que definem que outros "packages" devem estár previamente instalados no sistema.

As dependências são também importantes no que se refere à remoção ou actualização de "software" já que este tipo de operação pode ter consequencias sobre outro "software" instalado que é dependente do primeiro.

O sucesso deste tipo de gestores depende em larga medida da sua aceitação geral. Um dos mais conhecidos é o RPM ("Red Hat Package Manager"), incluido em muitas distribuições Linux tais como "Red Hat" ,"Suse", "Mandrake", ... .

Infelizmente, nem sempre se encontram disponíveis os "packages" que pretendemos, para a nossa plataforma, para facilitar esta tarefa, o RPM pode usar "packages" em formato "source", ou seja "software" sob a forma de código fonte, sem compilar, o RPM pode depois ser usado para proceder à compilação do código fonte, produzindo um "package" binário pronto a instalar.

Os "packages" em formato de código fonte, no caso do RPM são habitualmente conhecidos por SRC-RPM e a sua grande vantagem é poderem ser usados em qualquer plataforma, constituindo-se como alternativa quando não existe uma versão RPM (pré-compilada) disponível para uma dada plataforma, o seu inconveniente é que para efectuar a compilação (BUILD) é geralmente necessário instalar "software" adicional que não é necessário para usar as versões pré-compiladas.

Software Comercial

A maioria do software comercial, por razões obvias, é fornecido sob a forma pré-compilada e geralmente não utilizam os gestores de "software" existentes, em seu lugar disponibilizam um programa de instalação que se encarrega de verificar se a plataforma obdece aos requesitos pré-estabelecidos, estas verificações tentam determinar, por observação do sistema de ficheiros e realização de diversos testes se os pré-requesitos são atingidos. Algum deste "software" pré-compilado, de menor qualidade, pode mesmo não realizar verificações, deixando estas a cargo do administrador. Em certos casos, a instalação pode mesmo ser manual, obrigando o administrador a copiar os ficheiros da aplicação para os locais indicados.

Page 89: Analista de Sistema Operacional

A utilização destes programas de instalação tem o inconveniente, na maioria dos casos, de não actualizar a base de dados do gestor de "software", logo para o gestor esse "software" não existe no sistema, como consequencia a remoção ou actualização de programas do qual este "software" comercial depende vai ser permitida.

Software em código fonte

A maioria do "software" "open-source" encontra-se disponível sob a forma de código fonte simples, geralmente sob a forma de um arquivo em formato TAR, este arquivo contém um directório base dentro do qual se encontra uma árvore de directórios contendo as várias partes do código fonte. O "software" distribuído desta forma, pode em principio, ser instalado em qualquer tipo de sistema Unix, contudo trata-se de um processo um pouco mais moroso que envolve a compilação do código fonte.

Depois de extraidos os ficheiros do arquivo (para arquivos simples, com extensão [.tar] pode ser usado o comando tar xf, para arquivos comprimidos usando o gzip, geralmente com extensaão [.tgz] ou [.tag.gz], é necessária a opção z) obtem-se um directório de base no qual deve existir um programa de configuração, geralmente com o nome "configure".

O programa de configuração destina-se a verificar requesitos do sistema e adaptar o código fonte às particularidades do sistema, uma vez executado com sucesso, o "software" encontra-se pronto a ser compilado. O processo de compilação inicia-se com o comando "make" e pode ser algo moroso. Uma vez concluida a compilação com sucesso, geralmente é suportada o comando "make install" que vai copiar os ficheiros binários e outros para os locais apropriados e desta forma instalar a aplicação.

Embora o processo descrito acima seja quase "standard", nunca deve ser iniciado sem antes ler a documentação que acompanha o código fonte (geralmente ficheiros README ou INSTALL no interior do directório de base).

Instalação manual de "software"

Embora a instalação manual de "software" não seja actualmente muito conveniente, o conhecimento dos procedimentos envolvidos é muito importante porque permite ao administrador resolver problemas resultantes de instalações deficientes.

Em Unix para a instalação de aplicações é usado um conjunto de nomes de directório "standard" que é obrigatório conhecer, cada um destes directórios tem uma finalidade a respeitar:

• bin - destina-se a armazenar ficheiros executáveis (transformáveis em processos) por todos os utilizadores.

• sbin - destina-se a armazenar ficheiros executáveis (transformáveis em processos), mas não se pretende que sejam usados vulgarmente pelos utilizadores, destinam-se ao administrador e ao sistema.

• lib - contém bibliotecas dinâmicas que são carregadas pelos programas de acordo com as suas necessidades. Também pode ser usado para guardar ficheiros de configuração e mesmo de dados.

• etc - contém ficheiros de configuração das aplicações.

Page 90: Analista de Sistema Operacional

• var - contém ficheiros de dados das aplicações. • man - contém manuais de utilização e configuração das

aplicações, em formato apropriado ao programa man. • info - contém manuais de utilização e configuração das

aplicações, em formato apropriado ao programa info.

Este conjunto de directórios (ou parte deles) pode existir em vários pontos do sistema de ficheiros, esses pontos são o directório de base de instalação da aplicação, a instalação consiste basicamente na cópia de ficheiros para os subdirectórios apropriados do directório base:

• / (raiz) - os directórios da raiz são usados pelo "software" de base do sistema, as aplicações instaladas posteriormente não utilizam normalmente estes directórios, as excepções são os directórios /etc e /var que são usados por algumas aplicações para armazenar resepectivamente ficheiros de configuração e ficheiros de dados.

• /usr - este directório é muito utilizado como base de instalação para muitas aplicações, sendo por isso os respectivos executáveis colocados em /usr/bin e as bibliotecas em /usr/lib, os ficheiros de configuração deveriam ser colocados em /usr/etc, mas isso nem sempre acontece e por vezes é usado o directório /etc, o mesmo se passando para os dados relativamente ao directório var.

• /usr/local - esta é outra base de instalação muito usada, aplicando-se também o que foi dito para o directório de base /usr.

• Directórios exclusivos - uma aplicação também pode ser instalada num directório de base próprio, criado exclusivamente para a aplicação. Os locais mais habituais para estes directórios serem criados são /opt /usr/local e /usr/lib.

Muitas aplicações também criam ficheiros de configuração/dados nos directórios dos utilizadores, quando estes usam as aplicações pela primeira vez, isto permite uma personalização da configuração individual para cada utilizador.

A aplicação, uma vez instalada num dado directório base vai usar esse directório como base para encontrar os ficheiros de que necessita, nomeadamente de dados e de configuração. Se a aplicação sabe desde logo onde procurar os seus ficheiros, o mesmo não se pode dizer do sistema operativo. Neste aspecto existem 3 situações onde a interacção entre a aplicação e o sistema operativo pode ser afectada:

• Pesquisa de ficheiros executáveis

Para criar um novo programa em execução é necessário criar um novo processo (fork) e de seguida usar uma função "exec" para substituir o nove processo por um ficheiro binário. Para usar a função "exec", ou é especificado o caminho completo até ao ficheiro binário, ou então usa-se uma das funções "exec" que pesquisam a variável de ambiente PATH (exec?p). Este processo é normalmente levado a cabo pela "shell" do utilizador.

Quando um comando é invocado é normalmente pesquisada a variável PATH que contém uma sequência de directórios onde se pode encontrar

Page 91: Analista de Sistema Operacional

ficheiros binários, um habitual para esta variável é "/bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin". O conteúdo desta variável pode ser facilmente alterado pelo administrador através dos ficheiros /etc/profile, para a "shell" normal (sh/bash) e dos ficheiros /etc/csh.cshrc e /etc/csh.login, para a csh/tcsh. Deste modo quando se instala um novo programa, cujo executável não se encontra nos directórios habituais da variável PATH, basta editar estes ficheiros de configuração para adicionar o novo directório, onde se encontra o ficheiro executável, por exemplo "/usr/local/netscape/".

O problema é que as variaveis de ambiente podem ser alteradas pelo utilizador, por outro lado a variável PATH tende a crescer rápidamente com o aumento das aplicações instaladas. Uma alternativa, viável quando o directório contém um número reduzido de executáveis é criar uma ligação simbólica num directório que está na PATH, por exemplo "ln -s /usr/local/netscape/netscape /usr/local/bin/netscape".

• Carregamento de bibliotecas ligadas dinamicamente

A maioria dos programas compilados são incompletos, durante a operação de compilação a inserção de código contido em bibliotecas (linking) não é realizada, em seu lugar a, durante a execução do programa, as bibliotecas são carregadas em memória e usadas pelo programa. Este processo é conhecido por "dynamic linking" e é usado intensivamente nos sistemas operativos modernos como o MS-Windows, com as DLL, ou o Linux com as bibliotecas partilhadas ("Shared Libraries"), as bibliotecas partilhadas devem estár disponíveis para os programas quando estes são executados. O programa "ldd" permite saber a que bibliotecas está dinamicamente ligado um dado executável ligado, no exemplo seguinte pode ver-se o resultado dessa verificação sobre o executável /usr/local/netscape/netscape num dado sistema:

ldd /usr/local/netscape/netscape libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x4000c00 0) libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x4004e00 0) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40057 000) libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x4006c 000) libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x4007e 000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6

(0x4008c000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40097 000) libdl.so.1 => /lib/libdl.so.1 (0x40137000) libc.so.5 => /lib/libc.so.5 (0x4013a000) libg++.so.27 => /usr/lib/libg++.so.27 (0x401f6000) libstdc++.so.27 => /usr/lib/libstdc++.so.27

(0x4022e000) libm.so.5 => /lib/libm.so.5 (0x4025f000)

Do lado esquerdo pode observar-se os nomes das bibliotecas de que o programa necessita e do lado direito, onde foram encontradas no sistema de ficheiros. Como se pode observar os nomes destas bibliotecas são geralmente da forma [libNOME.so.NUMERO] quando usado, o número indica a versão da biblioteca. Por exemplo a biblioteca X11 encontra-se no directório /usr/X11R6/lib:

Page 92: Analista de Sistema Operacional

-rw-r--r-- 1 root root 1085674 Jan 31 2 001 /usr/X11R6/lib/libX11.a

lrwxrwxrwx 1 root root 13 Nov 30 15 :43 /usr/X11R6/lib/libX11.so -> libX11.so.6.1

lrwxrwxrwx 1 root root 13 Feb 22 2 001 /usr/X11R6/lib/libX11.so.6 -> libX11.so.6.1

-rwxr-xr-x 1 root root 663320 Jan 31 2 001 /usr/X11R6/lib/libX11.so.6.1

No caso podemos observar a existência de 4 entradas com a designação libX11, a entrada com extensõo .a destina-se a ser usada durante a compilação de programas ("static linking"), no final encontra-se a versão partilhada que será carregada pelo "netscape", embora o netscape deseje a versão 6, vai receber a versão 6.1, isso é conseguido usando uma ligação simbólica. As bibliotecas possuem normalmente dois números de versão, o primeiro ("major") é o mais significativo, sendo mantida a compatibilidade dentro de todas as sub-versões, por isso os programas são normalmente ligados apenas ao número de versão mais significativo.

A forma como as bibliotecas são procuradas é ligeiramente mais complexa do que o que acontece para os executáveis, as bibliotecas partilhadas são procuradas na seguinte ordem:

1. Nos directórios definidos na variável de ambiente LD_LIBRARY_PATH, por razões de segurança obvias (...) para os programas SETUID/SETGID isto é ignorado.

2. Na lista de bibliotecas contida no ficheiro /etc/ld.so.cache 3. No directório /usr/lib 4. No directório /lib

A lista de bibliotecas definida no ficheiro ld.so.cache não é manualmente editável porque não é um ficheiro de texto este ficheiro é usado pelo sistema para manter informação sobre as bibliotecas partilhadas que vão sendo usadas de forma a acelerar o processo de carregamento em futuras utilizações. A actualização deste ficheiro pode ser forçada com o comando "ldconfig". O comando ldconfig procura bibliotecas dinâmicas nos seguintes directórios:

o lista de directórios especificados na linha de comando (opcional)

o lista de directórios contidos no ficheiro /etc/ld.so.conf (um directório por linha)

o directórios /lib e /usr/lib

Além de actualizar a cache de bibliotecas que acelera o carregamento destas, o ldconfig também se encarrega de actualizar/corrigir as ligações simbólicas de acordo com os números de versão disponíveis. O programa "ldconfig" deve ser sempre invocado durante o arranque da máquina.

Quando se instala um programa que contém bibliotecas partilhadas, estas terão de estar acessiveis para o programa poder funcionar, se a base de instalação é o directório /usr, não existe qualquer problema, igualmente, se a base é /usr/local tal não apresenta grande problema porque o directório

Page 93: Analista de Sistema Operacional

/usr/local/lib é um dos que está normalmente registado no ficheiro /etc/ld.so.conf, por isso basta executar o comando "ldconfig" para actualizar a "cache".

Se o programa se instala num directório particular, por exemplo /usr/local/kde, a melhor solução é adicionar o directório que contém as respectivas bibliotecas ao ficheiro /etc/ld.so.conf e de seguida actualizar a "cache" com o comando ldconfig.

• Pesquisa de manuais pelos comandos do sistema (ex.: man, info)

O comando "man" utiliza procedimentos semelhantes aos usados para as bibliotecas dinâmicas, o sistema mantém uma "cache" das localização das páginas dos manuais usadas recentemente, o comando "mandb" actualiza essa informação em moldes semelhantes aos do comando "ldconfig", a lista de directórios a pesquisar está definida no ficheiro /etc/man_db.config, além disso o comando "man" também procura os manuais nos directórios definidos na variável de ambiente "MANPATH". O comando "manpath" pode ser usado pelos utilizadores para definir a variável PATH de acordo com a informação existente no ficheiro /etc/man_db.conf.

O comando "info" (e também o emacs) utiliza as variáveis de ambiente INFOPATH e INFODIR para procurar os documentos tipo "info", normalmente estas variáveis devem conter "/usr/info:/usr/local/info". Para estes documentos não existe "cache", quando um programa não tem como base de instalação /usr ou /usr/local pode ser necessário adicionar o novo directório às variáveis de ambiente, para isso será necessário editar os ficheiros /etc/profile e /etc/csh.cshrc.

Administração de Serviços

Os serviços de um sistema são um conjunto de meios que permitem um acesso organizado aos recursos, a maioria dos serviços destinam-se a acesso externo (via rede) o acesso interno (apartir da "shell") é muito mais directo e simples (acesso ao sistema de ficheiros, execução de comandos, ...) pelo que normalmente não é necessário recorrer a este conceito.

Um serviço de rede, que pretende facultar acesso a determinados recursos partindo do exterior do sistema tem de se preocupar com várias questões, tais como tipo de protocolo de comunicação usado, autenticação de utilizadores e filtragem de origens dos pedidos.

Os serviços de rede usam protocolos de rede para transporte de dados, em Unix os protocolos de eleição são o TCP e o UDP que por sua vez usam o IP ("Internet Protocol"), mas especialmente quando se fala de Linux existe um grande número de protocolos suportados, tais como o IPX ou o Appletalk. Os serviços locais utilizam mecanismos internos de comunicação (IPC) tais como "Sockets Unix", "Filas de Mensagens", "Pipes" (FIFOs) e memória partilhada.

Page 94: Analista de Sistema Operacional

Embora o Unix, e em particular o Linux, suportem outros protocolos de rede/transporte, existe uma clara ligação entre o Unix e a pilha TCP/IP, tal deve-se ao facto de o Unix ter sido a plataforma usada para o desenvolvimento do TPC/IP. Por sua vez o TCP/IP foi sempre a pilha mais usada pelo Unix, muitas implementações Unix apenas suportam TCP/IP e praticamente todos os sistemas operativos Unix suportam TCP/IP.

Os serviços são quase todos implementados segundo o modelo "Cliente-Servidor", neste modelo o servidor é uma aplicação passiva que aguarda o contacto de um cliente, quando tal acontece "acorda" e presta o serviço pedido. O suporte de multiplas comunicações independentes com processos no interior de uma dada máquina é assegurado através da multiplexagem da interface-de-rede/endereço-de-máquina através dos números de porto ou porta ("port number").

Consultar o documento Redes, endereços, nomes e serviços - introdução.

Na pilha TCP/IP existem dois protocolos disponíveis para a implementação de serviços, o UDP e o TCP:

• UDP - O "User Datagram Protocol" é um protocolo sem ligação que se destina à troca de blocos isolados de informação, é um protocolo não fiável, isto é não se garante que os dados chegam ao destino e só em algumas situações é que o emissor tem conhecimento de que os dados não chegaram ao destino. Dadas estas caracteristicas o UDP apenas é adquado a serviços simples, sem sessão/ligação, com volumes muito reduzidos de dados e sem grandes exigencias de fiabilidade.

• TCP - O "Transmission Control Protocol" é um protocolo fiável com controlo de fluxo e erros, com ligação, uma vez estabelecida a ligação as comunicações entre os dois processos envolvidos funcionam sobre um canal lógico dedicado, não acessível a outros processos. O TCP é o protocolo escolhido sempre que o serviço implica a definição de uma sessão/ligação. Mesmo que o serviço não implique o estabelecimento de ligação/sessão, se os volumes de dados são elevados o UDP coloca dificuldades e deverá optar-se pelo TCP.

Uma das caracteristicas que um serviço deve ter é estar permanentemente disponível, independentemente do número de clientes que estãao a ser atendidos. A implementação das aplicações servidoras tem de atender a este aspecto e às caracteristicas do protocolo usado:

• Servidores UDP - para cada porta de destino (serviço), com o protocolo UDP apenas é possível distinguir um processo servidor de destino no interior da máquina, isso significa que um único processo servidor vai ter de atender todos os clientes. Este facto introduz limitações no serviço porque o servidor deverá ser do tipo sem-estado ("stateless"), ou seja cada pedido deve ser autonomo e não depender de outros pedidos anteriores.

Esta limitação é muito importante porque para usar UDP com serviços onde existe o conceito de sessão essa funcionalidade terá de ser totalmente implementada nas aplicações servidora e cliente e o servidor torna-se

Page 95: Analista de Sistema Operacional

extremamente complexo porque tem de manter multiplas sessões de diversos clientes num único processo. Mais importante ainda esta limitação dificulta a transferência de grandes quantidades de dados, se a quantidade de dados é superior à permitida para um "datagrama" UDP, terão de ser usados vários "datagramas", mas estes terão de constituir pedidos totalmente independentes. A disponibilidade permanente do serviço é aparente, enquanto o servidor está a atender um cliente, outros pedidos, de outros clientes são armazenados em fila de espera ("buffer"), quando o servidor acaba de processar um pedido lê o seguinte do "buffer".

Por estas razões o UDP apenas é normalmente usado para serviços muito simples que consistem no envio de apenas um pedido e recepção de uma resposta, ambos de reduzida dimensão. Um exemplo não típico é o serviço TFTP ("Trivial File Transfer Protocol") que é um serviço de acesso a ficheiros, normalmente em modo de leitura-apenas que é muito usado para o arranque de postos de trabalho sem disco. O TFTP usa o protocolo UDP, para o conseguir, os ficheiros são divididos em blocos 512 bytes (para "caberem" num "datagrama" UDP), o cliente envia pedidos isolados ao servidor contendo o nome do ficheiro e número do bloco pretendido, todo o controlo fica a cargo do cliente, por exemplo se um bloco não é recebido o cliente terá de efectuar novamente o pedido.

• Servidores TCP - o protocolo TCP é muito mais elaborado, com o TCP é possível distinguir vários processos servidores de destino no interior da máquina, essa distinção baseia-se no porto/endereço-de-origem dos dados. Quando um processo servidor TCP recebe um pedido de ligação de um cliente gera-se um novo descritor que representa a ligação estabelecida, neste descritor todos os dados recebidos vem do cliente ligado e todos os dados emitidos serão recebidos apenas pelo cliente ligado, esta caracteristica permite definir este protocolo como sendo do tipo "com-ligação", os dados não são enviados em blocos como no UDP, mas sim em fluxo contínuo. Além deste aspecto o TCP é fiável porque implementa mecanismos de controlo de fluxo e erros baseado no protocolo de janela deslizante orientado a caractere.

Estas caracteristicas do protocolo TCP tornam muito simples a implementação de serviços com sessão, quando o processo servidor recebe um pedido de ligação gera-se um novo descritor ligado ao novo cliente, neste momento o servidor cria um novo processo ("fork") que usa apenas o novo descritor para atender em exclusivo o novo cliente, o processo pai continua a atender pedidos de ligação. O tempo de indisponibilidade do serviço é muito menor, limitando-se ao tempo necessário para criar um novo processo.

Em TCP a questão da quantidade de dados a transferir não se coloca porque os dados são transmitidos em fluxo continuo, sem qualquer espécie de limitação.

Podemos então considerar dois tipos de servidor básico, os servidores UPD asseguram serviços simples sem ligação, são constituidos por um único processo que atende todos os pedidos de todos os clientes, quando existe um grande número de clientes, o tempo de resposta é afectado segundo o modelo das filas de espera M/D/1.

Page 96: Analista de Sistema Operacional

Os servidores TCP proporcionam serviços fiáveis, com ligação, o servidor TCP é constituido por um processo que recebe os pedidos de ligação dos clientes, quando recebe um pedido cria um novo processo que trabalha em exclusivo para o novo cliente, os tempos de resposta sob pressão de um grande número clientes não são significativos porque existem processos servidores dedicados a cada cliente. Para serviços simples, os servidores UDP são mais eficientes em tempo de resposta porque não necessitam de criar um novo processo.

Os sistemas tipo Unix são adequados a muitas finalidade, mas a sua eficiência e fiabilidade tornaram-nos a primeira escolha como plataforma para a implementação de serviços. Os serviços devem estár disponíveis imediatamente depois do arranque do sistema, os processos servidores são criados apartir dos "scripts" de boot de sistema, de acordo como o que está definido no ficheiro /etc/inittab, geralmente estes "scripts" encontram-se dentro do directório /sbin/init.d/, o exemplo seguinte mostra parte do ficheiro /sbin/init.d/apache :

case "$1" in start) if test -x /usr/sbin/httpd ; then echo "Starting WWW-Server apache." /usr/sbin/httpd -f /etc/httpd/httpd.conf fi ;; stop) if [ -f /var/run/httpd.pid ] ; then echo -n "Shutting down Apache HTTP server" kill `cat /var/run/httpd.pid` rm -f /var/run/httpd.pid else echo -n "Apache not running?" fi echo ;; restart) if [ -f /var/run/httpd.pid ] ; then echo -n "Reload Apache configuration" kill -1 `cat /var/run/httpd.pid` else echo -n "Apache not running?" fi echo ;; *) echo "Usage: $0 {start|stop|restart}" exit 1 esac

Este script é automaticamente executado durante o arranque do sistema, com o argumento "start", pode observar-se que o processo servidor é criado por invocação do binário /usr/sbin/httpd que trata de criar o processo servidor.

O "Internet Super-Server" (inetd)

É comum um sistema Unix prestar dezenas ou centenas de serviços distintos, em principio seria necessário ter em execução outros tantos processos servidores. Embora um processo servidor não apresente grande consumo de capacidade de processamento

Page 97: Analista de Sistema Operacional

quando não está a atender clientes, usa alguma memória central, e mesmo que tal não seja muito significativo pode considerar-se um despedicio de recursos porque são processos que até existir algum cliente "não fazem nada".

O "Internet Super-Server" (inetd) resolve esta situação, a ideia é ter um único processo que assegure o atendimento de todos os diversos tipos de serviço necessários no sistema. É claro que o "inetd" não possui as funcionalidades dos diversos tipos de serviço, para isso recorre a programas externos. O "inetd" limita-se a escutar as várias portas de serviço, quando chega um pedido "passa a batata quente" a um programa externo específico para esse serviço.

O programa "inetd" consulta o ficheiro de configuração /etc/inetd.conf, neste ficheiro encontram-se definidos os serviços que devem ser assegurados pelo "inetd", um serviço por linha, cada linha contém os seguintes campos separados por espaços:

• Nome do serviço - representa na realidade o número de porto, o "Nome de serviço" deve estar definido no ficheiro /etc/services.

• Tipo de serviço - define o tipo de serviço, este valor está directamente relacionado com o protocolo e corresponde aos valores estabelecidos para a "system-call" "socket". Os valores mais usados são "stream" para serviços TCP com ligação ou o valor "dgram" para o serviço de "datagramas" UDP.

• Protocolo - trata-se da designação do protocolo usado, estes nomes estão registados no ficheiro /etc/protocols, os valores mais usados são "tcp" e "udp".

• Modo - este campo pode ter os valores "wait" ou "nowait", está relacionado com o funcionamento interno do "inetd" que será abordado a seguir.

• Nome de Utilizador - identifica o nome do utilizador com que o serviço será prestado (executado), normalmente é "root", mas para serviços que não necessitam de acessos especiais ao sistema pode ser usado um nome de utilizador sem direitos especiais tal como "nobody". O nome de utilizador pode ser seguido de um nome de grupo (separado por um ponto).

• Programa servidor e argumentos - trata-se do nome do programa que o "inetd" invocará para prestar o serviço, este campo é constiuido por uma sequência de argumentos em formato apropriado para a função "execl", ou seja o nome do executável com o caminho completo até ele, novamente o nome do executável, e depois os argumentos.

O exemplo seguinte apresenta um extracto de um ficheiro /etc/inetd.conf:

echo dgram udp wait root internal daytime dgram udp wait root internal time stream tcp nowait root internal ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd telnet stream tcp nowait root /usr/sbin/t cpd in.telnetdsmtp stream tcp nowait root

/usr/sbin/sendmail sendmail -bs shell stream tcp nowait root /usr/sbin/tcpd in.rs hd -pop3 stream tcp nowait root /usr/sbin/popper poppe r - stftp dgram udp wait.400 root /usr/sb in/tcpd

in.tftpd /tftpboot bootps dgram udp wait root /usr/sbin/bootpd bootpd - d4

Page 98: Analista de Sistema Operacional

finger stream tcp nowait nobody /usr/local/libexec/in.xfingerd in.xfingerd -b dc=p t

systat stream tcp nowait nobody /bin/ps ps - auwwxnetstat stream tcp nowait root /bin/netstat netst at - netbios-ssn stream tcp nowait root /usr/sbin/smbd

smbd -s /etc/smb.conf netbios-ns dgram udp wait root /usr/sbin/nmbd

nmbd # End.

O "inetd" assegura alguns serviços básicos sem recurso a programas externos, nesses casos (3 primeiras linhas do exemplo) usa-se a palavra "internal" em lugar do nome do executável externo. O programa "tcpd" é um auxiliar que realiza algumas validações da proveniencia dos pedidos e será abordado adiante. O funcionamento do "inetd" pode ser descrito do seguinte modo:

1. O ficheiro de configuração /etc/inetd.conf é lido, o ficheiro é lido novamente sempre que o processo "inetd" recebe o sinal "HUP".

2. São abertos os "sockets" apropriados a cada serviço e associados ao respectivo número de porto.

3. É utilizada a "system-call" "select" para saber se chegou um "datagrama" (dgram/udp) ou um pedido de ligação (stream/tcp) em qualquer dos portos de serviço.

4. Quando chegam dados, é criado um novo processo, no novo processo:

1. o UID/GID é alterado para corresponder ao que está definido para esse serviço.

2. os descritores "standard" de entrada e saída de dados são fechados (close(0);close(1);) e o "socket" é duplicado (dup2) para esses descritores.

3. é usada a função "execl" para substitui o processo pelo executável, tal como está especificado para esse serviço. 5. No processo original (inetd) a "system-call" "select" é novamente

invocada para detectar novos pedidos nos "sockets". Se o serviço está definido como sendo em modo "nowait", então o "socket" correspondente ao serviço também vai ser monitorizado, se o modo é "wait" o "socket" fica suspenso e não é monitorizado. Neste último caso o "socket" só volta a ser monitorizado quando o processo que foi criado para atender o pedido anterior terminar.

Os serviços com ligação (stream/tcp) podem ser sempre do tipo "nowait" porque para cada cliente é criado um "socket" independente ("system-call" "accept"), assim o "inetd" pode atender imediatamente novos pedidos para esse serviço. Pelo contrário, para os serviços sem ligação deverá ser sempre usado o modo "wait" porque só existe um "socket" e consequentemente não podem existir dois processo a usa-lo, apenas quando o novo processo termina é possível o "inetd" voltar a receber pedidos desse serviço. Por esta razão os servidores UDP devem ter tempos de execução o mais curtos possíveis, além disso se um destes servidores "encrava", o serviço fica bloqueado.

Imediatamente a seguir ao modo wait/nowait pode ser colocado um número, separado por um ponto que indica o número máximo de processos que podem ser

Page 99: Analista de Sistema Operacional

criados por minuto para atender o serviço, se nada for indicado o valor usado pelo "inetd" é normalmente de 40.

Os servidores executáveis, invocados pelo "inetd" para prestar os serviços utilizam a entrada "standard" para receber dados do cliente (STDIN/Descritor 0) e a saída "standard" para enviar dados ao cliente (STDOUT/Descritor 1). Isto significa que os servidores invocados pelo "inetd" não necessitam de ser aplicações especificamente desenvolvidas para trabalhar em rede, no exemplo acima pode observar-se que as linhas correspondentes aos serviços "systat" e "netstat" utilizam comandos habitualmente usados na "shell", por exemplo, quando o comando "ps" é invocado escreve o seu resultado no descritor 1, como o "inetd" duplicou o descritor do "sochet" de rede para o descritor 1, o resultado é enviado ao cliente, no caso através de um "datagrama" UDP.

O "xinetd" é uma versão melhorada do "inetd", utiliza o ficheiro de configuração /etc/xinetd.conf, mas pode ser realizada a inclusão de outros ficheiros de configuração, geralmente usa-se um directório /etc/xinetd.d/ para esse efeito, o "xinetd" é semelhante ao "inetd", o formato dos ficheiros de configuração é diferente, mas o conteúdo essencialmente o mesmo, ao contrário do "inetd", o "xinetd" permite filtrar os endereços de origem dos pedidos, para se conseguir isso com o "inetd" é necessário recorrer a um programa auxiliar, o "tcpd".

Os sistemas Linux possuem uma biblioteca para implementação de filtragem de pedidos, essa biblioteca "libwrap.a" ("Access Control Library) define funções para realizar diversos tipos de validação, a validação (para cada serviço) pode basear-se em "nome do cliente", "endereço do cliente", "nome do utilizador", "nome do processo servidor", "nome do servidor", "endereço do servidor" e utiliza dois ficheiros de configuração: /etc/hosts.allow e /etc/hosts.deny. Estes ficheiros usam mascaras para identificar os clientes. Primeiro é verificado se o cliente se ajusta a alguma definição no /etc/hosts.allow, se isso acontecer o acesso é imediatamente autorizado. Se não, então será verificado se o cliente está abrangido pelo /etc/hosts.deny, se isso acontece o acesso é negado, caso contrário é autorizado.

O programa "tcpd" ("TCP/IP Daemon Wrapper Program") destina-se a servir de intermediário entre o "inetd" e servidores que não suportam esta biblioteca de controlo de acesso. O "inetd" invoca o "tcpd" em lugar do servidor, o "tcpd" determina o número de porto/serviço a que estão associados os descritores (0/1) ("system-call" "getsockname") e valida o acesso usando a "libwrap", se o acesso é válido utiliza uma função "exec" para se substituir pelo verdadeiro servidor. Como se pode observar no exemplo anterior, o "tcpd" não necessita de uma especificação do executável servidor ao estilo função "exec", basta o nome do executável e os respectivos argumentos, o "tcpd" permite que o nome do executável seja especificado sem caminho, nesse caso o executável será procurado num directório pré-definido, normalmente /usr/bin/.

Em termos de validação de acessos, a utilização do "xinetd" é vantajosa porque apesar de não ter tantas possibilidades de configuração como a "libwrap" usada pelo "tcpd" garante uma negação de acesso mais directa. A combinação "inetd/tcpd" obriga a criar um novo processo mesmo que depois o cliente não seja autorizado. Isso pode facilitar ataques de negação de serviço (saturação de pedidos).

Page 100: Analista de Sistema Operacional

Confiança entre sistemas Unix

A relação de confiança entre certos servidores é um conceito actualmente suportado por quase todos os sistemas operativos com pretenções a servirem de plataforma a servidores. Estas relações de confiança, geralmente definidas entre sistemas com administração comum visam aumentar a cooperação entre servidores, permitindo uma melhor distribuíção dos serviços e facilitando a administração. No limite o conjunto de servidores cooperantes pode funcionar como um todo e apresentar neste ponto de vista capacidade impossíveis de atingir com um único sistema.

A cooperação entre sistemas envolve a existência de comunicações entre eles, na maioria dos casos sob a forma de prestação de serviços, o problema é que grande parte destes serviços são sensiveis sob o ponto de vista de segurança e por isso é necessário utilizar mecanismos de autenticação que tornam as operações mais pesadas.

Os sistemas Unix utilizam um mecanismo muito simples que dispensa a utilização de processos pesados de autenticação, este mecanismo baseia-se apenas nos protocolos de comunicação e aproveita o facto de apenas o administrador poder usar portos UDP/TCP com valores inferiores a 1024, conhecidos normalmente por "portos reservados".

No sistema que presta o serviço (servidor) definem-se estaticamente, os endereços de rede (IP) dos clientes de confiança, quando o servidor recebe um pedido consulta esta informação e compara o endereço de origem para saber se o cliente é de confiança. Em sistemas multi-utilizador esta verificação é insuficiente, é necessário saber se foi o utilizador "root" que emitiu o pedido, para isso o cliente tem de usar um porto inferior a 1024, assim o servidor além de verificar se o endereço de origem corresponde a uma máquina de confiança tem também de verificar se o porto de origem é inferior a 1024, nessas condiçõo o servidor sabe que o pedido provém do utilizador "root" na "máquina de confiança".

Por ser extremamente simples este mecanismo é muito eficiênte, mas baseia toda a validação no endereço de origem o que pode não ser totalmente seguro.

Este mecanismo é usado por vários serviços tais como "Remote Shell/Remote Copy" (rcp/rsh/rshd), "Remote Login" (rlogin/rlogind) e "Line Printer" (lpr/.../lpd), todos estes servidores usam o ficheiro de configuração /etc/hosts.equiv onde se encontram definidos os nomes/endereços dos "clientes de confiança". Muitos destes comandos destinam-se a ser invocados directamente pelo utilizidor, para conseguirem abrir um porto reservado (<1024) são SETUID "root".

Uma outra aplicação importante do conceito de "sistema de confiança" é no NFS ("Network File System"), este sistema de servidores de ficheiros foi desenvolvido especificamente no contexto Unix e é radicalmente diferente dos outros servidores de ficheiros mais comuns.

Enquanto os servidores de ficheiros mais conhecidos como Windows (SMB) e NetWare (NCP) baseiam este tipo de serviço no estabelecimento prévio de uma sessão de utilizador (geralmente autenticada por "username/password"), os servidores NFS disponibilizam ficheiros a máquinas clientes e não a utilizadores em particular. A

Page 101: Analista de Sistema Operacional

configuração de um servidor NFS (mountd/nfsd) baseia-se no ficheiro /etc/exports, neste ficheiro são definidos os directórios a exportar (sub-directórios automaticamente incluidos) e uma lista de clientes (máquinas/endereços) que podem usar cada um dos directórios, para este efeito os clientes referênciados aqui são considerados de confiança. Para cada cliente é possível ainda especificar diversas opções relativas ao modo como o directório é exportado, o extracto seguinte apresenta um ficheiro /etc/exports:

# This file contains a list of all directories expo rted to other computers.

# It is used by rpc.nfsd and rpc.mountd. /tftpboot/192.168.0.1 linuxbox(rw,no_root_squash) /usr/local *(ro) newhost(rw) /cdrom1 *(ro)

Neste exemplo pode observar-se que os directórios /usr/local e /cdrom1 são exportados para todos os clientes (*), em modo de leitura apenas (ro), sendo um acesso apenas de leitura e não sendo a informação confidencial, permite-se deste modo um acesso público a estes directíorios. O cliente "newhost" tem no entanto acesso de escrita (rw) ao directório /usr/local.

O directório /tftpboot/192.168.0.1 é exportado em modo "read-write" para o cliente "linuxbox", é usada ainda a opcão "no_root_squash". Os pedidos envidos ao servidor NFS transportam sempre o UID/GID do utilizador que os desencadeou no cliente, no servidor esse UID/GID é usado no acesso ao directório local, por esta razão é conveniente que os UID/GID sejam os mesmos no cliente e no servidor, para isso basta centralizar a base de dados de utilizadores, por exemplo recorrendo a um servidor NIS.

A utilização no servidor NFS do UID na máquina cliente tem uma excepção, por razões de segurança quando o servidor NFS recebe um pedido do UID=0 (root) não usa esse UID no servidor, em seu lugar usa o utilizador "nobody", esta medida de segurança pode ser desactivada usando a opção "no_root_squash", tal como se pode observar no exemplo acima. O operação se alteração de UID entre cliente e servidor é conhecida por "squashing" e sendo automática para o UID=0 pode ser forçada para outros UIDs.

O servidor NFS apenas aceita pedidos provenientes de portas reservadas (<1024), o cliente NFS está integrado no núclo do sistema operativo da máquina cliente, o acesso ao servidor estabelecido pelo administrador usando o comando "mount", geralmente é colocada uma entrada no /etc/fstab para que seja realizado durante o arranque do sistema.

Na máquina cliente, a forma como os utilizadores acedem ao sistema de ficheiros é de total responsabilidade da administração local, uma vez montado, o directório remoto torna-se acessível localmente como qualquer outro sistema de ficheiros.

Uma das grandes vantagens dos servidores NFS é que não têm estado ("stateless"), apenas facultam operações deleitura e escrita, não disponibilizando as operações de abertura e encerramento do ficheiro, por esta razaão se um servidor NFS é reinicializado, os clientes não perdem informação, apenas existe uma indisponibilidade temporária.

Page 102: Analista de Sistema Operacional

Segurança da confiança baseada em endereços

O mecanismo de confiança entre máquinas baseado nos endereços de origem dos pedidos tem a grande vantagem de ser muito ligeiro e logo muito eficiênte sob o ponto de vista de performance, contudo a sua aplicação deve ter em consideração que se um intruso conseguir forjar o endereço de uma máquina de confiança, tudo está perdido. Desde logo este mecanismo só deve ser usado sob endereços de rede que são geridos pelo mesmo administrador dos sistemas, geralmente todos pertencentes a uma mesma rede.

Embora se trate de forjar o endereço de origem do pedido, o intruso tem também de se assegurar que recebe os dados de resposta, isto complica bastante a tarefa, considerando que as máquinas de confiança se encontram todas numa mesma rede local, a menos que o servidor verdadeiro esteja inactivo, é impossível realizar o ataque porque ao existirem duas máquinas com o mesmo endereço torna-se imprevisivel a qual das máquinas vão ser entregues os dados que de qualquer forma não serã legiveis porque são apenas fragmentos.

Uma abordagem possível seria desencadear um ataque duplo, por um lado bloquear o servidor verdadeiro com um ataque de negação de serviço (inundação de pedidos) e simultaneamente usar outra máquina para simular o endereço do servidor verdadeiro.

O ataque descrito é possível se os servidores usarem ARP dinâmico (situação usual). Para fazer os dados chegar ao destino dentro de uma rede local, o endereço IP não é suficiente porque a infra-estrutura de comunicação usada (ex: ethernet) usa outro formato de endereços conhecidos por endereços físicos ou endereços MAC. Assim cada sistema Unix mantém uma tabela de equivalencias entre endereços IP locais e endereços MAC locais que lhe permite fazer chegar os dados ao destino correcto dentro de uma rede local.

Para evitar a definição estática das tabelas MAC é usado um protocolo auxiliar, o ARP ("Address Resolution Protocol") que permite determinar quando necessário, qual o endereço MAC correspondente a um dado endereço IP. Para evitar o recurso sistemático a este protocolo, as equivalencias IP/MAC são guardadas numa tabela interna (tabela ARP), quando determinadas via protocolo ARP, as entradas nesta tabala são temporárias e são eliminadas depois de estarem algum tempo sem serem usadas. O problema do protocolo ARP é que não tem qualquer segurança, explicado de forma simples funciona do seguinte modo: é enviado a todos os nós da rede ("broadcast") um pedido para que o detentor do endereço IP do qual se pretende o MAC responda, ao obter a resposta fica-se a conhecer o endereço MAC.

Como é obvio qualquer nó da rede que diga ser o detentor desse endereço IP vai ser aceite. A alternativa é utilizar uma tabela ARP estática, isso obriga o administrador a inserir com a ajuda do comando "arp" entradas na tabela, inseridas deste modo estas entradas são permanentes e o protocolo ARP nunca será usado para elas.

As tabelas ARP estáticas aumentam um pouco a segurança, e inviabilizam a maioria dos ataques, embora afectem o funcionamento do sistema verdadeiro, não será possível ao intruso realizar operações sobre os sistemas aproveitando o estatuto de

Page 103: Analista de Sistema Operacional

confiança. Com ARP estático o intruso é obrigado é obrigado a simular não apenas o endereço IP, mas também o endereço MAC, a maioria das interfaces de rede e respectivos "device drivers" actuais permitem que o endereço MAC seja alterado. Os efeitos da existência de dois nós com o mesmo endereço MAC numa mesma rede inviabilizam na maioria dos casos a comunicação, os efeitos exactos dependem da infra-estrutura de comunicação, por exemplo se se trata de um meio de "broadcast" simples ou de uma rede com comutação.

Na eventualidade de o sistema verdadeiro estar inactivo (sem comunicações), a tarefa do intruso fica muito facilitada, se for usado ARP dinâmico, basta usar na máquina intrusa o mesmo IP do sistema verdadeiro, se for usado ARP estático terá também de ser simulado o enderço MAC.

Para resolver o problema só existe uma via segura: evitar o acesso físico à rede onde se encontram os servidores. Esta configuração corresponde aliás ao modelo mais aconselhado para implementação de "intranets" com ligação á "internet". Aconselha-se vivamente que a rede onde se encontram os sistemas servidores esteja isolada e não seja a mesma rede onde os utilizadores trabalham, este tipo de rede isolada, exclusiva para servidores corresponde ao que se designa vulgarmente por rede desmilitarizada (DMZ - "DeMilitarized Zone"). A ligação desta rede à "internet" e à "intranet" é assegurada por um ou mais "routers"/"firewalls".

Page 104: Analista de Sistema Operacional

1

Devido a expansão do uso de computadores em instituições de ensino; no setor comercial e emresidências tornou-se interessante a interconexão destes equipamentos formando um poderoso eeficiente meio de comunicação que permite usufruir além do simples compartilhamento de recursoscomo impressora e espaço em disco (mídia fixa ou removível). Conforme a evolução das tecnologias aplicadas, acredita-se que em breve as redes decomputadores poderão ser o principal veículo de comunicação.

1. Introdução:

A comunicação para a humanidade é algo natural pois nenhum ser consegue viverisoladamente, e desde seu surgimento pode-se observar o desenvolvimento de técnicas para suprir estanecessidade de contato com outrém. Isto pode ser exemplificado com a evolução dos toques de tambor e uso de sinais de fumaça porpombos-correio; o surgimento do telégrafo em 1838 e seu desenvolvimento até a presente data com ouso de rádios, televisores; até as comunicações via satélite. Centrando a atenção ao desenvolvimento da informática (que oferecia riscos às organizaçõespois defeitos no equipamento causavam a paralização de todo o serviço) para o surgimento deminicomputadores e posteriormente microcomputadores, onde a utilização de redes de informaçãoproporcionou melhorias na estruturação organizacional. Dessa forma, a descentralização do processamento também permitiu o compartilhamento derecursos (como meios de armazenamento de dados, impressoras, softwares, por exemplo), maiorconfiabilidade, modularidade do sistema, novos serviços dentre outras vantagens que facilitou acomunicação entre pessoas.

2. Evolução dos Sistemas de Computação

Como pode ser observado na figura 1, a evolução da eletrônica e microeletrônica possibilitou ademocratização dos computadores que eram enormes e de altíssimo custo até os microcomputadorespresentes em casas e escritórios por todo o mundo.

Redes

Page 105: Analista de Sistema Operacional

2

Assim como o desenvolvimento dos equipamentos, a necessidade de comunicação e utilizaçãode redes pode ser observada consultando o arquivo “guia do professor para internet” para conhecer acronologia e desenvolvivento da Internet.

3. Arquiteturas de Redes

3.1. Introdução

A tarefa de permitir a comunicação entre aplicações executando em máquinas distintas envolveuma série de detalhes que devem ser cuidadosamente observados para que esta comunicação ocorra demaneira precisa, segura e livre de erros. Por exemplo, detalhes de sinalização dos bits para envioatravés dos meios de transmissão; detecção e correção de erros de transmissão (pois a maioria dosmeios de transmissão são passíveis de interferências); roteamento das mensagens, desde sua origem atéo seu destino, podendo passar por várias redes intermediárias; métodos de endereçamento tanto dehosts quanto de aplicações; cuidar da sintaxe e semântica da informação, de modo que quando umaaplicação transmite um dado do tipo inteiro, a aplicação destino possa entendê-lo como do tipo inteiro;etc.

Para reduzir a complexidade de projeto, a maioria das redes de computadores são estruturadasem camadas ou níveis, onde cada camada desempenha uma função específica dentro do objetivomaior que é a tarefa de comunicação. As camadas são construídas umas sobre as outras e cada camadaoferece seus serviços para as camadas superiores, protegendo estas dos detalhes de como os serviçosoferecidos são de fato implementados.

A camada N em uma máquina, para desempenhar suas funções estabelece uma conversaçãocom a camada N em outra máquina. As regras utilizadas nesta conversação são chamadas deprotocolo da camada N. As funções de cada camada são executadas por entidades (processos, quepodem ser implementados por software ou por hardware). Entidades que executam em camadascorrespondentes e em máquinas distintas são chamadas de processos pares (peers). São os processospares que se comunicam utilizando o protocolo de sua camada. A figura 2 ilustra estes conceitos parauma rede estruturada em 4 camadas.

Figura 2: Exemplo de uma rede estruturada em 4 camadas.

Na verdade, nenhum dado é transferido diretamente da camada N de uma máquina para acamada N de outra máquina. Em vez disso, cada camada passa dados e informações de controle para acamada imediatamente abaixo, até encontrar o meio físico, através do qual a comunicação de fato

Page 106: Analista de Sistema Operacional

ocorre. Na máquina destino a mensagem percorre o caminho inverso, da camada mais inferior para amais superior, com cada camada retirando e analisando as informações de controle colocadas pela suacamada correspondente na máquina origem. Após esta análise a camada decide se passa o restante dosdados para a camada superior. Estas informações de controle correspondem ao protocolo da camada etambém são conhecidos como header do protocolo.

Para ilustrar o conceito de comunicação através de múltiplas camadas, consideremos a seguinteanalogia:

• Dois engenheiros em países diferentes desejam trocar informações sobre um projeto deengenharia. Um engenheiro só fala português e o outro só se comunica em inglês. Para secomunicarem eles decidem utilizar um tradutor;

• Considere ainda, que o idioma comum entre os tradutores seja o alemão e que o meioutilizado para transmissão dos dados seja o telégrafo;

• Assim, o engenheiro que fala português passa suas informações para seu tradutor que astraduz para o alemão. A mensagem em alemão é então passada ao telegrafista que astransmite para um telegrafista no outro país;

• Ao receber a mensagem, o telegrafista passa para o tradutor que a traduz para o inglês e aentrega para o engenheiro. A figura 3 ilustra essa comunicação, identificando oscomponentes da Arquitetura de Rede utilizada.

Figura 3: Exemplificação de uma Arquitetura de comunicação.

Nota-se que existe uma interface entre cada par de camadas adjacentes. É ela que definirá quaise como as funções oferecidas pela camada inferior podem ser acessadas pela camada superior. Estainterface deve ser bastante clara, de modo que, ao trocar-se a implementação de uma camada por outracompletamente diferente, não seja necessário modificar as outras camadas. Isso é possível desde que ainterface entre as camadas seja mantida. Por exemplo, trocando-se linhas telefônicas por transmissãovia satélite, a implementação da camada responsável por manipular o acesso ao meio de transmissãodeverá modificar completamente sua implementação, porém as demais camadas não sofrerão estasmodificações desde que os mesmos serviços anteriores e o modo como são oferecidos sejam mantidos.

Neste contexto o conjunto das camadas e protocolos é chamado de ARQUITETURA DEREDE.

Page 107: Analista de Sistema Operacional

4

3.2. Padrões para Interconexão de Redes de Computadores

As primeiras arquiteturas de rede foram desenvolvidas por fabricantes de equipamentos, osquais desenvolviam soluções para interconexão apenas de seus produtos, sem se preocuparem com acompatibilidade de comunicação com equipamentos de outros fabricantes. Assim o fizeram, porexemplo, a IBM (International Business Machines Corporation) ao anunciar sua arquitetura de redeSNA (System Network Architecture), e a DEC (Digital Equipament Corporation) com sua DNA(Digital Network Architecture). Essas arquiteturas são denominadas proprietárias.

Desse modo, computadores de fabricantes diferentes não podiam se comunicar, impondo umagrande limitação aos consumidores, pois ficam “amarrados” aos produtos de um único fabricante, casoqueira que seus equipamentos se comuniquem.

Torna-se evidente a necessidade de um conjunto de regras que permitam a comunicação ouinterconexão entre dois sistemas quaisquer, sem considerar seu fabricante. Surgem as arquiteturas parainterconexão de sistemas abertos: a Arquitetura Internet, desenvolvida por pesquisadorespatrocinados pelo Departamento de Defesa dos Estados Unidos, e a Arquitetura OSI (Open SystemsInterconnection) desenvolvida pela comunidade internacional sob a coordenação da ISO(International Standards Organization).

3.3. Arquitetura ISO/OSI

Baseada nas experiências advindas do funcionamento dos sistemas de teleprocessamento, daARPAnet1 e das redes públicas e proprietárias, a ISO, entre 1978 e 1984, elaborou o "Modelo deReferência para Interconexão de Sistemas Abertos" (Modelo OSI), o qual define todos os princípiosbásicos para o desenvolvimento de uma arquitetura para interconexão de Sistemas Abertos.

O Modelo OSI por si só não é uma arquitetura de rede, pois não especifica exatamente osserviços e protocolos a serem usados em cada camada. Ele define alguns conceitos e divide a tarefa decomunicação em sete camadas funcionais, dizendo que funções cada camada deve desempenhar.Entretanto, após elaborar o Modelo OSI, a ISO passou a projetar, especificar, implementar e testar osprotocolos das várias camadas definidas pelo Modelo OSI, dando origem a Arquitetura OSI.

Neste curso nos limitaremos a citar somente a estrutura de camadas e as respectivas funções decada camada como definido pelo Modelo OSI, sem entrar em detalhes dos protocolos de cada camada.As sete camadas do Modelo OSI estão representadas na Figura 4. Segue à figura uma descrição sucintada função de cada camada.

Apresentação

Sessão

Transporte

Rede

Enlace de Dados

Física

Aplicação

Figura 4: Estrutura de camadas do Modelo OSI. 1A ARPAnet foi a primeira rede de computadores baseada na comutação de pacotes e que deu origem a INTERNET.

Page 108: Analista de Sistema Operacional

5

3.3.1. Camada Física

A função desta camada é lidar com a transmissão pura de bits através de um canal decomunicação. Deve garantir que, quando um lado transmite um bit 1, este seja recebido como um bit 1do outro lado, e não como um bit 0. Portanto, o protocolo da camada física deve considerar questõescomo: voltagem para bit "1"; voltagem para bit "0“; tempo de duração de um bit; o modo detransmissão (simplex, half-duplex, full-duplex); como a conexão é estabelecida e encerrada; pinagemdos conectores e etc. Ou seja, questões mecânicas, elétricas e funcionais da transmissão dos bits.

3.3.2. Camada de Enlace de Dados

A principal função desta camada é detectar e, opcionalmente, corrigir possíveis erros quepossam ocorrer durante a transmissão sobre o meio físico. Para isso, ela particiona os dados recebidosda camada de rede em quadros (frames), algumas centenas de bits a serem enviados ao nível físico,adcionando seus headers para controle de erros. Também deve cuidar da retransmissão de framesdanificados ou perdidos e resolver problemas de duplicação de frames. Por exemplo, um ruído no meiode transmissão pode destruir o frame sendo transmitido. Neste Caso, a camada de Enlace de Dados namáquina origem deve retransmitir o frame. Entretanto, múltiplas retransmissões introduzem apossibilidade de frames duplicados.

Outras tarefas desta camada são processar avisos de confirmação de recebimento enviados peloreceptor e resolver problemas de conexão entre máquinas com velocidades diferentes (quando umamáquina transmite dados em uma velocidade maior do que a máquina destino pode suportar, ocorreráum estouro de buffer na máquina destino e os dados podem ser perdidos).

3.3.3. Camada de Rede

Esta camada controla a operação da subnet de comunicação. Sua tarefa principal estárelacionada com o problema de como os pacotes de informação são roteados da máquina origem até amáquina destino. As rotas podem ser baseadas em tabelas estáticas embutidas na rede e que raramentesão modificadas. Elas também poderiam ser definidas no início de uma conversa, por exemplo, umasessão de terminal, ou finalmente, poderiam ser altamente dinâmicas, modificando-se a cada pacotetransmitido e refletindo a carga atual da rede.

Outras tarefas da camada de rede são: controle de congestionamento e tráfego; estatística de usopor usuário; resolver problemas de incompatibilidades (ex.: formas de endereçamento; tamanho depacotes de dados; protocolos diferentes, etc) que podem ocorrer quando um pacote "viaja" por váriasredes até alcançar a máquina destino.

Em redes do tipo broadcast, devido à existência de um único canal, a função principal destacamada (roteamento) torna-se irrelevante.

3.3.4. Camada de Transporte

A camada de rede não garante necessariamente que um pacote chegue a seu destino, e pacotespodem ser perdidos ou mesmo chegar fora da seqüência original de transmissão. A função básica destacamada é aceitar os dados da camada de sessão, quebrá-los em partes menores se necessário, passá-losà camada de rede e garantir que as partes cheguem em ordem no destino. Isso tudo deve ser feitoindependentemente da tecnologia da subnet usada. Desse modo, a camada de transporte isola ascamadas superiores das mudanças inevitáveis na tecnologia de hardware.

Page 109: Analista de Sistema Operacional

6

Para cada requisição de conexão vinda da camada de sessão, a camada de transporte cria umaconexão de rede distinta. Entretanto, no caso de uma requisição de conexão de alto desempenho, acamada de transporte pode criar múltiplas conexões de rede para uma única sessão, aumentando odesempenho. Do mesmo modo, a fim de reduzir custos, várias requisições distintas de sessão podemser multiplexadas em uma única conexão de rede.

Em máquinas multiprogramadas, várias aplicações podem estar ativas "simultaneamente". Comisso, múltiplas conexões podem estar saindo e entrando de cada máquina. Portanto, quando umamensagem chega em uma máquina, deve haver alguma maneira de identificar a qual conexão(conseqüentemente, para qual aplicação) ela pertence. A camada de transporte deve fornecer estemecanismo de identificação de aplicações.

3.3.5. Camada de Sessão

Sua tarefa é permitir que usuários em máquinas diferentes estabeleçam sessões entre eles. Umasessão permite a um usuário, por exemplo, realizar um login em um sistema de tempo compartilhadoremoto ou transferir um arquivo entre duas máquinas. Esta camada é responsável por resolver todos osproblemas que possam ocorrer durante uma sessão. Por exemplo:

• controle de diálogo: quando somente um lado da conexão pode transmitir em um dadoinstante (half-duplex), um mecanismo de tokens pode ser usado pela camada de sessão paraesse fim;

• sincronização da comunicação: coloca pontos de checagem (sincronização) que permitem,

em caso de quebra da comunicação, o reestabelecimento da comunicação a partir do último

ponto de sincronização checado. Ex. Transferência de arquivos.

3.3.6. Camada de Apresentação

Ao contrário das demais camadas que estão preocupadas em transferir dados de maneiraconfiável, a camada de Apresentação cuida da semântica e sintaxe da informação transferida. Elapermite que dados representando uma cadeia de caracteres, números reais ou inteiros, ou estrutura dedados, cheguem à máquina destino com o mesmo significado semântico e sintático com que foramtransmitidos, independentemente dos diferentes padrões de codificação utilizados pelas máquinasenvolvidas na comunicação. Isto é possível através da definição de dados em um modo abstrato, osquais podem ser convertidos para a representação padrão da rede. Por exemplo, suponhamos que amáquina A vai transmitir o número inteiro de dois bytes com valor 5 para a máquina B. Suponha aindaque a máquina A utilize uma representação Big Endian, onde o byte mais significativo é o daesquerda, e a máquina B utilize uma representação Little Endian, com byte mais significativo à direita.Ao receber o dado e transformá-lo na sua representação, a máquina B entenderia o número como tendoo valor 1280, ao invés de 5 como foi transmitido pela máquina A. Este problema é ilustrado na figuraabaixo.

Page 110: Analista de Sistema Operacional

7

000 0 0 0 0 0

Big Endian Little Endian

Máquina A Máquina B

== 5 1280

110 0 0 0 0 0 000 0 0 0 0 0 110 0 0 0 0 0

0x28 + 5x20 5x280x20 +

Figura 5: Problema na comunicação entre máquinas com diferentes formas de representação de dados.

3.3.7. Camada de Aplicação

Fornece o suporte necessário para interação (comunicação) entre aplicações distribuídas,formando a interface entre um processo de usuário e os protocolos de comunicação. Nela estãoserviços que são comumente necessários, tais como correio eletrônico, transferência e acesso aarquivos remotos, login remoto, etc.

3.4. Transmissão de Dados no Modelo OSI

A figura 6 mostra como ocorre a transmissão de dados quando um usuário em um sistema Aenvia uma mensagem para um usuário em um sistema B, segundo o modelo OSI.

Figura 6: Transmissão de Dados no modelo OSI.

O processo começa com a entrega dos dados a serem transmitidos pelo usuário para a camadade aplicação na máquina A. A camada de aplicação junta aos dados do usuário um cabeçalho (header)contendo informações de controle de protocolo. Após isso, os dados do usuário, juntamente com oheader anexado pela camada de aplicação são enviados para a camada de Apresentação. Para que possa

Page 111: Analista de Sistema Operacional

8

executar sua função, esta também anexa suas informações de controle de protocolo e repassa os dadospara a camada abaixo, ou seja, a camada de Sessão. Esse processo é feito na máquina A até que cadacamada faça sua função, ou seja, anexe seus headers de controle. Ao atingir a camada física namáquina A, os dados são transmitidos pelo meio de transmissão, juntamente com os headers colocadospelas camadas.

Na máquina B, ocorre o processo inverso. À medida que os dados vão sendo passados para ascamadas superiores, cada camada retira o header colocado por sua camada correspondente na máquinaorigem (máquina A), executa as operações do protocolo de acordo com as informações contidas noheader, e passa o restante para a camada superior. O processo se encerra com o usuário no sistema Brecebendo os dados enviados pelo usuário do sistema A.

Page 112: Analista de Sistema Operacional

Nos anos 60, o principal setor estratégico americano, Department of Defense – DoD se interessou em um protocolo que estava sendo desenvolvido/utilizado pelas universidades para interligação dos seus sistemas computacionais e que utilizava a tecnologia de chaveamento de pacotes. O interesse do DoD estava no desejo de manter a comunicação entre os diversos sistemas espalhados pelo mundo, no caso de um desastre nuclear. O problema maior estava na compatibilidade entre os sistemas computacionais de diferentes fabricantes que possuíam diferentes sistemas operacionais, topologias e protocolos. A integração e compartilhamento dos dados passou a ser um problema de difícil resolução.

Foi atribuído assim à Advanced Research Projects Agency – ARPA a tarefa de encontrar uma solução para este problema de tratar com diferentes equipamentos e diferentes características computacionais. Foi feita então uma aliança entre universidades e fabricantes para o desenvolvimento de padrões de comunicação. Esta aliança especificou e construiu uma rede de teste de quatro nós, chamada ARPANET, e que acabou sendo a origem da Internet hoje.

No final dos anos 70, esta rede inicial evoluiu, teve seu protocolo principal desenvolvido e transformado na base para o TCP/IP (Transmition Control Protocol / Internet Protocol). A aceitação mundial do conjunto de protocolos TCP/IP deveu-se principalmente a versão UNIX de Berkeley que além de incluir estes protocolos, colocava-os em uma situação de domínio público, onde qualquer organização, através de sua equipe técnica poderia modificá-los e assim garantir seu desenvolvimento.

Dentre as várias organizações e comitês que participaram deste desenvolvimento e divulgação, podemos destacar Internet Engineering Task Force – IETF (http://www.ietf.org) cuja principal função atual é a manutenção e apoio aos padrões da Internet e TCP/IP principalmente através da série de documentos Request for Comments - RFC. Estes documentos descrevem as diversas tecnologias envolvidas e servem de base para as novas tecnologias que deverão manter a compatibilidade com as anteriores dentro do possível.

Em resumo, o maior trunfo do TCP/IP é o fato destes protocolos apresentarem a interoperabilidade de comunicação entre todos os tipos de hardware e todos os tipos de sistemas operacionais. Sendo assim, o impacto positivo da comunicação computacional aumenta com o número de tipos computadores que participam da grande rede Internet.

Protocolos

Page 113: Analista de Sistema Operacional

2. Modelo de Referência ISO/OSI

Dentro deste cenário de grande variedade de sistemas operacionais, CPUs, interfaces de rede, tecnologias e várias outras variáveis, e a necessidade de interconexão entre os diversos sistemas computacionais, em 1977, a International Organization for Standardization – ISO, criou um sub-comitê para o desenvolvimento de padrões de comunicação para promover a interoperabilidade entre as diversas plataformas. Foi então desenvolvido o modelo de referência Open Systems Interconnection – OSI.

É importante observar que o modelo OSI é simplesmente um modelo que especifica as funções a serem implementadas pelos diversos fabricantes em suas redes. Este modelo não detalha como estas funções devem ser implementadas, deixando isto para que cada empresa/organização tenha liberdade para desenvolver.

O comitê ISO assumiu o método “dividir para conquistar”, dividindo o processo complexo de comunicação em pequenas sub-tarefas (camadas), de maneira que os problemas passem a ser mais fáceis de tratar e as sub-tarefas melhor otimizadas. O modelo ISO/OSI é constituído por sete camadas, descritas sucintamente a seguir de cima para baixo:

7 Aplicação Esta camada funciona como uma interface de ligação entre os processos de comunicação de rede e as

aplicações utilizadas pelo usuário.

6 Apresentação Aqui os dados são convertidos e garantidos em um formato universal.

5 Sessão Estabelece e encerra os enlaces de comunicação.

4 Transporte Efetua os processos de sequenciamento e, em alguns casos, confirmação de recebimento dos pacotes de dados.

3 Rede O roteamento dos dados através da rede é implementado aqui.

2 Enlace Aqui a informação é formatada em quadros (frames). Um quadro representa a exata estrutura dos dados

fisicamente transmitidos através do fio ou outro meio.

1 Física Define a conexão física entre o sistema computacional e a rede. Especifica o conector, a pinagem, níveis de tensão, dimensões físicas, características mecânicas e elétricas,

etc.

Page 114: Analista de Sistema Operacional

CBPF-NT-004/2000

________________________________________________________________________________________________ Protocolos TCP/IP 04/04/01 5/19

Cada camada se comunica com sua semelhante em outro computador. Quando a informação é passada de uma camada para outra inferior, um cabeçalho é adicionado aos dados para indicar de onde a informação vem e para onde vai. O bloco de cabeçalho+dados de uma camada é o dado da próxima camada. Observe a figura abaixo que esquematiza isto.

A unidade de informação muda de nome ao longo das camadas de maneira que podemos saber sobre qual camada se está referindo pelo nome destas unidades. A tabela abaixo relaciona os diversos nomes destas unidades de informação ao longo das camadas:

7 Aplicação Mensagem

4 Transporte Segmento

3 Rede Datagrama

2 Enlace Quadro/Frame

1 Física Bit

Antes do desenvolvimento do modelo de camadas ISO/OSI, o DoD definiu seu próprio modelo de rede conhecido como modelo DoD de rede ou também modelo Internet de rede. Posteriormente este modelo passou a ser conhecido como modelo de camadas TCP/IP, que será descrito a seguir.

Page 115: Analista de Sistema Operacional

CBPF-NT-004/2000

________________________________________________________________________________________________ 6/19 04/04/01 Protocolos TCP/IP

3. Modelo TCP/IP

O modelo de camadas ISO/OSI acabou se tornando apenas uma base para praticamente todos os protocolos desenvolvidos pela indústria. Cada desenvolvedor tem uma arquitetura que difere em detalhes as vezes fundamentais no seu desenvolvimento. Sendo assim, é de se esperar uma variação nas descrições do conjunto de protocolos TCP/IP. Apresentaremos a seguir a comparação entre duas possíveis interpretações, esquerda e direita do modelo base ISO/OSI ao centro:

Na figura acima, vemos que a tabela da esquerda apresenta os principais protocolos distribuídos pelas diversas camadas, enquanto que na tabela da direita as funções são o destaque.

Na tabela da esquerda vemos que o TCP/IP não faz distinção entre as camadas superiores. As três camadas superiores são estritamente equivalentes aos protocolos de processos da Internet. Os processos possuem o nome do próprio protocolo utilizado porém é importante não confundir o protocolo em si com a aplicação que geralmente apresenta uma interface com usuário amigável para utilização do protocolo.

No modelo ISO/OSI, a camada de transporte (4) é responsável pela liberação dos dados para o destino. No modelo Internet (TCP/IP) isto é feito pelos protocolos “ponto a ponto” TCP e UDP que serão descritos posteriormente.

Por fim, o protocolo IP é o responsável pela conexão entre os sistemas que estão se comunicando. Basicamente este protocolo se relaciona com a camada de rede (3) do modelo ISO/OSI. Este protocolo é o responsável principal do movimento da informação na rede. É nesta camada/protocolo que a informação é fragmentada no sistema fonte e reagrupada no sistema alvo. Cada um destes fragmentos podem ter caminhos diferentes pela rede de forma que os fragmentos podem chegar fora de ordem. Se, por exemplo, o

Page 116: Analista de Sistema Operacional

CBPF-NT-004/2000

________________________________________________________________________________________________ Protocolos TCP/IP 04/04/01 7/19

fragmento posterior chegar antes do anterior, o protocolo IP no sistema destino reagrupa os pacotes na seqüência correta.

Na tabela de direita consideramos o TCP/IP como sendo constituído por 4 camadas apenas. A camada superior, camada de aplicação/processo é responsável por permitir que aplicações possam se comunicar através de hardware e software de diferentes sistemas operacionais e plataformas. Muitas vezes este processo é chamado de cliente-servidor. A aplicação cliente em geral está em um equipamento mais simples e com uma boa interface com usuário. Esta aplicação envia requisições à aplicação servidor que normalmente está em uma plataforma mais robusta e que tem capacidade para atender várias requisições diferentes de clientes diferentes.

A camada que segue, camada de Transporte ou “Ponto a Ponto”, tem a função principal de começar e terminar uma conexão e ainda controlar o fluxo de dados e de efetuar processos de correção e verificação de erros.

A camada de rede é a responsável pelo roteamento. Comparativamente ela corresponde no modelo ISO/OSI a camada de Rede (3) e parte da camada Enlace (2). Esta camada é usada para atribuir endereço de rede (IP) ao sistema e rotear a informação para a rede correta. Tem ainda a função de ligação entre as camadas superiores e os protocolos de hardware. Em essência podemos afirmar que sem esta camada, as aplicações teriam que ser desenvolvidas para cada tipo de arquitetura de rede como por exemplo Ethernet ou Token Ring.

A primeira camada, camada Física, não é definida pelo TCP/IP, porém é nítida sua importância em relação à parte física da mídia de comunicação, de bits, de quadros, de endereços MAC, etc.

4. Endereçamento IP e Classes

Como visto anteriormente, a camada do protocolo IP ou protocolo Internet, define um endereço de identificação único e através deste endereço executa serviços de roteamento que basicamente definem o caminho disponível naquele momento para comunicação entre a fonte e o destino.

O protocolo Internet (IP) necessita da atribuição de um endereço Internet (endereço IP) organizado em 4 octetos (bytes). Estes octetos definem um único endereço dividido em uma parte que representa a rede a qual pertence o endereço, em alguns casos a subrede também, e por fim a representação particular daquele sistema na rede.

Alguns endereços possuem significado especial:

?? Endereço 0: Significa a própria rede ou sistema. O endereço 0.0.0.35 referencia a estação 35 da rede local. O endereço 127.0.0.0 referencia a estação em análise. O endereço

Page 117: Analista de Sistema Operacional

CBPF-NT-004/2000

________________________________________________________________________________________________ 8/19 04/04/01 Protocolos TCP/IP

152.84.40.0 referencia a subrede 40 inteira da rede local do CBPF que pode ser representada por 152.84.0.0.

?? Endereço 127: É conhecido como loopback e é utilizado em processos de diagnose. O endereço 127.0.0.1 é o próprio loopback da estação em análise.

?? Endereço 255: Este endereço é muito utilizado em mensagens broadcast e serviços de anúncio generalizados. Uma mensagem enviada para o endereço 152.84.255.255 irá atingir todos os 255 sistemas de cada uma das 255 subredes da rede local do CBPF.

A tabela a seguir relaciona os diversos aspectos relevantes na definição do endereço Internet: o número de sistemas possíveis, os primeiros bits do primeiro octeto e os seus possíveis valores. Os demais octetos podem assumir livremente os valores entre 0 e 255, sempre levando em conta aqueles de significado especial.

Classe 2n Hosts Bits IniciaisPrimeiro Octeto

A 24 167.772 0xxx 0-127 B 16 65.536 10xx 128-191 C 8 256 110x 192-223 D - - 1110 224-239 E - - 1111 240-255

Os endereços Classe A são usados para redes muito grandes normalmente ligada a funções educacionais e científicas. Os endereços Classe B são usados em redes muito grandes, normalmente atribuídas a instituições que possuíam um perfil disseminador de tecnologia e assim pudessem de alguma forma distribuir suas redes entre instituições e empresas contribuindo assim para o desenvolvimento de uma grande rede mundial. Os endereços Classe C são os mais difundidos pois permitem redes de 256 IP’s o que parece ser um número conveniente para gerenciamento e implantação de sistemas de informação. Os endereços Classe D são reservados para Multicast utilizado nas aplicações de Videoconferência, Multimídia, dentre outras, e por fim, os endereços Classe E são reservados para experimentação e desenvolvimento.

5. Subredes

A criação de subredes a partir de uma rede primária é um procedimento típico na área de redes. O objetivo desta segmentação é permitir uma melhor performance da rede em termos organizacionais, estruturais e funcionais.

Page 118: Analista de Sistema Operacional

CBPF-NT-004/2000

________________________________________________________________________________________________ Protocolos TCP/IP 04/04/01 9/19

Rede Sub Sistema 31 23 15 9 0

Máscara de Subrede 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0

31 23 15 9 255.255.255.252

A idéia básica é acrescentar alguns bits à identificador de rede do endereço Internet. Os endereços permitidos são aqueles formados pelos bits restantes do octeto. Veja figura anterior.

5.1. Máscara de Subredes

Conforme descrito na figura anterior, o identificador de redes e subredes, a máscara de subrede, também é composta por 4 octetos. A máscara é formada por bits 1 nos campos que caracterizam o endereço de rede, e bits 0 nos campos relativos ao host.

Considere uma Classe C com cada posição representada por um único bit de um endereço de 32bits:

R -> Rede H -> Host RRRRRRRR.RRRRRRRR.RRRRRRRR.HHHHHHHH

Se esta Classe C for dividida em 8 subredes com 32-2(rede e broadcast)=30 hosts em cada uma delas, a máscara será 255.255.255.224 ou ainda /27 e sua representação fica:

RRRRRRRR.RRRRRRRR.RRRRRRRR.RRRHHHHH 11111111.11111111.11111111.11100000

Em um outro exemplo queremos fazer 64 subredes com 4-2=2 hosts permitidos por subrede. Neste caso a máscara seria 255.255.255.252 ou ainda /30 com a seguinte representação:

RRRRRRRR.RRRRRRRR.RRRRRRRR.RRRRRRHH 11111111.11111111.11111111.11111100 O mesmo raciocínio pode ser empregado em uma Classe B ou Classe

A, mudando somente a relação entre bits 1 e bits 0, ou em outras palavras muda o octeto em análise. No caso de 2 subredes na Classe B teremos 255.255.128.0 ou /17 representadas por:

RRRRRRRR.RRRRRRRR.RHHHHHHH.HHHHHHHH 11111111.11111111.10000000.00000000

Vale ressaltar aqui uma operação simples implementada por todos algoritmos de roteamento que é o AND lógico entre a máscara de subrede e o

Page 119: Analista de Sistema Operacional

CBPF-NT-004/2000

________________________________________________________________________________________________ 10/19 04/04/01 Protocolos TCP/IP

endereço do host. Se o endereço tiver os mesmos bits 1 da máscara então este endereço pertence a subrede em análise e portanto o pacote pode ser enviado através de broadcast na subrede. Se diferir, então o pacote deve ser enviado ao gateway, pois certamente pertence a outra subrede.

6. Protocolos e Aplicações

Neste capítulo abordaremos os principais protocolos que compõem o conjunto TCP/IP de protocolos. Alguns destes protocolos são confundidos pela própria aplicação que os utiliza. Sendo assim, adiante haverá uma seção de Protocolos de Aplicação.

6.1. Protocolo Internet - IP

O protocolo Internet é definido na camada 3 do modelo ISO/OSI. Esta camada é responsável pelo endereçamento dos pacotes de informação dos dispositivos origem e destino e possível roteamento entre as respectivas redes, se diferentes. Este roteamento é executado através do IP.

Como visto anteriormente, o endereço IP é composto de 4 octetos, que são divididos em parte rede e parte dispositivo, chamados de identificadores de rede e de host, de acordo com o tipo de classe definido pelos primeiros bytes do primeiro octeto, e/ou subrede, definida pelo número de máscara.

Este protocolo, usando a parte rede do endereço ou identificador de rede, pode definir a melhor rota através de uma tabela de roteamento mantida e atualizada pelos roteadores.

Este protocolo recebe os dados da camada superior (transporte) na forma de segmentos. Ocorre então o processo de fragmentação e os conjuntos de dados passam a se chamar datagramas. Estes datagramas são então codificados para envio à camada inferior (física) para encaminhamento no meio físico.

Na tabela abaixo relacionamos as diversas partes (9) constituintes de um datagrama, o número de bits e função ou descrição.

O primeiro campo, Cabeçalho, contém informação sobre a versão do número IP (ipv4 ou ipv6) e o tipo de serviço (ToS), muito usado em aplicações que necessitem de Qualidade de Serviço (QoS).

O segundo campo, Comprimento, informa o comprimento do datagrama incluindo dados e cabeçalho.

O terceiro campo, Fragmentação, instrui ao protocolo, como reagrupar datagramas quando chegam após um processo de fragmentação muito comum em interfaces defeituosas e tráfego intenso.

Page 120: Analista de Sistema Operacional

CBPF-NT-004/2000

________________________________________________________________________________________________ Protocolos TCP/IP 04/04/01 11/19

O quarto campo, Time to Live – TTL, informa o número de roteadores que podem redirecionar o datagrama. O valor é decrementado até zero a cada roteador quando então o datagrama é descartado, impedindo a criação de loops e assim garantindo estabilidade ao processo de roteamento.

1 2 3 4 5 6 7 8 9

Bits 32 16 16 8 8 16 32 32 xxx

Des

criç

ão

Cab

eçal

ho

Co

mp

rim

ento

Fra

gm

enta

ção

TT

L

Pro

toco

lo T

CP

ou

UD

P

Ver

ific

ação

de

Err

os

En

der

eço

Fo

nte

En

der

eço

Des

tin

o

Dad

os

O quinto campo, informa qual protocolo deverá receber o datagrama na próxima camada. Se o valor deste campo for 6, TCP, se 7, UDP. Estes protocolos serão descritos posteriormente.

O sexto campo, Verificação de Erro, seleciona que processo será utilizado na detecção de erros: Cyclical Redundance Check – CRC ou Frame Check Sequence – FCS.

Os próximos campos, sétimo e oitavo, Endereço Fonte e Endereço Destino, 32 bits cada, caracterizam por completo toda informação sobre endereçamento necessária ao processo de roteamento.

O último campo contém os dados, a informação na realidade, e tem tamanho livre porém definido pelo tipo de rede sendo o MTU igual a 1500kbytes.

Todas as informações necessárias para que o IP possa se comunicar com o resto da rede estão distribuídas nestes campos, principalmente naqueles relativos ao endereçamento. É importante observar que a camada de rede utiliza estes endereços lógicos de 4x8bits, para definir as redes existentes e como conseguir obter informação delas. Entretanto, para que os dados cheguem aos hosts é necessário um outro tipo de endereço: endereço Media Access Control - MAC ou Ethernet.

O TCP/IP define um protocolo, ARP, que caracteriza e relação entre o endereço IP e o endereço MAC. Falaremos a seguir sobre este protocolo.

Page 121: Analista de Sistema Operacional

CBPF-NT-004/2000

________________________________________________________________________________________________ 12/19 04/04/01 Protocolos TCP/IP

6.2. Address Resolution Protocol - ARP

Na realidade, a troca de dados entre dispositivos IP é efetuada através do endereço MAC - Media Access Control, ou endereço Ethernet ou ainda endereço Físico. De maneira bem simplificada, podemos considerar o protocolo ARP como sendo um broadcast no segmento de rede perguntando qual é o endereço MAC do dispositivo que tem um certo IP.

Vamos considerar a figura abaixo através de dois exemplos típicos: comunicação no mesmo segmento de rede e em redes distintas.

Vamos considerar primeiramente uma aplicação no computador A enviando dados para o computador B, considere por simplicidade um serviço PING de A para B. O primeiro passo é determinar se A e B pertencem ao mesmo segmento de rede. Isto é feito através do simples algoritmo que compara o resultado de uma operação AND lógico entre os IP e a sua respectiva máscara: mesmo resultado mesma rede, resultados diferentes redes diferentes. No caso A e B são vizinhos de um mesmo segmento.

Na construção do datagrama, a aplicação sabe os endereços MAC e IP da fonte A e somente o endereço IP do destino B. Para descobrir o endereço MAC de B o protocolo ARP envia um broadcast a todos os dispositivos do segmento perguntando ao dono do IP B o seu endereço MAC. Por sua vez, o dispositivo dono do IP, envia também por broadcast, ou seja, para todos, o seu endereço MAC. Todos os dispositivos do segmento acrescentam na sua tabela ARP (IPxMAC), também chamada de proxycache ARP, este registro relativo ao B, que permanece durante um certo tempo. Finalmente, o dispositivo A envia o quadro (frame) destinado ao dispositivo B. Neste exemplo o mesmo quadro é enviado para B e a interface do roteador deste segmento, porém somente o dispositivo B irá abrir o quadro até a última camada pois somente ele tem o endereço MAC destino. Observe que se houvesse outros dispositivos no segmento, eles passariam a conhecer também o endereço MAC de B de maneira que se quiserem enviar algo à B posteriormente, não seria mais necessário um broadcast ARP.

Vamos agora considerar que a comunicação seja entre os dispositivos A e C. Primeiramente o dispositivo A determina que C pertence a outro

Page 122: Analista de Sistema Operacional

CBPF-NT-004/2000

________________________________________________________________________________________________ Protocolos TCP/IP 04/04/01 13/19

segmento através do algoritmo comparativo de operações AND. O dispositivo A então envia os dados para o gateway que é a interface do roteador. Para isto o protocolo ARP é utilizado para descobrir o endereço MAC da interface da mesma maneira que no caso anterior. Observe que o endereço MAC destino é do roteador porém o IP destino continua sendo do dispositivo C. Quando o roteador recebe os dados, ele procura pela rede à qual pertence o IP destino na sua tabela de roteamento e assim roteia para interface deste segmento. O roteador irá utilizar o protocolo ARP para determinar o endereço MAC do dispositivo C que será anexado ao cabeçalho da camada de enlace, como MAC destino e o seu próprio como MAC origem. É importante observar que os IPs origem (A) e destino (C) permanecem inalterados durante todo o processo. Quando o dispositivo C finalmente recebe a mensagem oriunda de A, o processo de volta é simplificado pois os diversos endereços MAC continuam nas tabelas dos dispositivos envolvidos (C, roteador e A).

Estes dois exemplos simples mostram o funcionamento e importância do protocolo ARP que na realidade só é usado para manter a tabela IP/MAC de cada dispositivo atualizada.

6.3. Internet Control Message Protocol - ICMP

O ICMP é um protocolo de mensagens de controle usado para informar outros dispositivos de importantes situações das quais podemos citar como exemplo: fluxo de mensagens maior que a capacidade de processamento de um dispositivo; parâmetro Time To Live – TTL; e mensagens de redirecionamento. Abordaremos rápida e separadamente cada um destes três exemplos.

Eventualmente um roteador pode estar recebendo mais informação do que pode processar, sendo assim ele passa a contar com controle de fluxo, enviando uma mensagem source quench para o dispositivo origem para que ele pare ou diminua o fluxo de dados. Esta mensagem é enviada pelo protocolo ICMP.

O segundo caso evolve o parâmetro TTL que basicamente é o número de hops (roteadores) total que uma informação pode percorrer. Ele é decrementado a cada hop e quando chega a zero, o roteador descarta o datagrama e envia uma mensagem à fonte informando que a informação não chegou ao seu destino, utilizando o ICMP.

O terceiro caso é a mensagem de redirecionamento ICMP, que é utilizada quando o roteador determina que um caminho melhor existe para o pacote que acabou de ser enviado assim mesmo. Neste caso a implementação do protocolo de roteamento pode definir um novo caminho de acordo com este melhor caminho. Alguns sistemas operacionais de roteamento não consideram esta mensagem e continuam enviando dados pelo pior caminho.

Page 123: Analista de Sistema Operacional

CBPF-NT-004/2000

________________________________________________________________________________________________ 14/19 04/04/01 Protocolos TCP/IP

Uma aplicação típica deste protocolo é o PING, muito utilizado para determinar se um determinado dispositivo está ativo em uma rede, já que esta aplicação testa o sistema de transporte do TCP/IP.

6.4. Transmission Control Protocol - TCP

O protocolo IP, camada de rede (3), envia dados para rede sem a preocupação de verificar a chegada dos respectivos datagramas. Os protocolos da camada acima, host-host ou transporte (4), especificamente TCP, definem a maneira para tratar datagramas perdidos ou corruptos. Além disto, TCP é responsável pela segurança na transmissão/chegada dos dados ao destino e também define todo o processo de início de conexão e multiplexação de múltiplos protocolos da camada de aplicação (7) em uma única conexão, otimizando assim a conexão múltipla de aplicações com o mesmo destino.

O protocolo TCP é orientado a conexão sendo isto claramente observado no processo de inicialização da conexão. O TCP aplica o algoritmo three-way handshake ou three-fold nesta inicialização. Este algoritmo pode ser comparado com o ato de telefonar onde em um primeiro momento um número é discado, posteriormente alguém atende dizendo “alô” e por fim a pessoa que ligou começa a falar, enviando dados.

Na realidade, o dispositivo fonte envia uma seqüência de números que iniciará o envio de segmentos (vide final da seção 2), início de uma conexão SYN. Sendo assim o dispositivo destino passa a conhecer esta seqüência. O dispositivo destino responde com sua própria segundai de números e portanto o dispositivo fonte passa por sua vez, a conhecer a seqüência do destino, viabilizando assim a conexão pois os dispositivos envolvidos, fonte e destino, sabem as respectivas seqüências numéricas. Esta segunda etapa é conhecida como acknowledgment ou ACK. Na terceira e última etapa, o dispositivo fonte emite o seu sinal ACK informando que começará a enviar dados.

Assim como o IP, o TCP precisa saber qual o protocolo de aplicação da última camada que receberá os dados. Isto é feito através da codificação das portas. Ao todo são 65.535 (64k) portas, sendo que de 0 à 1024 são portas definidas e portanto só podem ser usadas por aplicações que utilizem os respectivos protocolos. As portas de 1024 à 65535 são atribuídas dinamicamente. Existem exceções que podem ser ignoradas nesta discussão.

6.5. User Datagram Protocol - UDP

Existem situações em que o dispositivo origem não precisa da garantia de chegada dos dados no dispositivo destino, como exemplo podemos citar alguns tipos de Videoconferência. Nestes casos, o TCP é substituído pelo UDP que é um protocolo que não é orientado a conexão, ou seja, não necessita estabelecer uma conexão entre origem e destino antes de enviar os dados. Este protocolo não verifica nem se o dispositivo destino está on line.

Page 124: Analista de Sistema Operacional

CBPF-NT-004/2000

________________________________________________________________________________________________ Protocolos TCP/IP 04/04/01 15/19

Na realidade o protocolo UDP empacota os dados e os envia para camada inferior (rede 3) para que o protocolo IP dê prosseguimento ao envio dos dados. Estes pacotes, segmentos, apesar de serem numerados antes de serem enviados, não sofrem nenhuma verificação de chegada ao destino.

Assim como fizemos um paralelo entre TCP e o telefone, podemos comparar o UDP com o correio regular. Preparamos uma carta, envelopamos, selamos e colocamos no correio na esperança de que chegue ao seu destino.

Assim como o TCP, o UDP também é um protocolo da camada de transporte (4), porém diferentemente não gera mensagens ICMP.

6.6. Protocolos da Camada de Aplicação

Como foi visto anteriormente, o conjunto de protocolos TCP/IP estão distribuídos ao longo das camadas superiores se comparados com o modelo ISO/OSI. Dentre estes, existem muitos protocolos que atuam na última camada (Aplicação). Abordaremos a seguir os mais utilizados pela comunidade.

6.6.1. File Transfer Protocol - FTP

A aplicação FTP foi uma das primeiras aplicações na hoje chamada Internet. A base é o protocolo FTP que tem como principal função a transferência de arquivos entre dispositivos nos formatos ASCII e Binário. É uma aplicação do tipo cliente/servidor e em uma situação típica a aplicação cliente FTP utiliza o protocolo TCP para estabelecer uma conexão com o servidor remoto. Os servidores podem disponibilizar áreas só de leitura para download de arquivos compartilháveis ou leitura/escrita para áreas públicas sem restrição.

Normalmente estes servidores permitem conexão autenticada, login/senha, com usuários cadastrados para acesso em áreas do servidor restritas ou ainda usuário anonymous ou mesmo ftp, com senha livre, normalmente o e-mail, para posterior contato. É importante observar que neste processo de autenticação o login/senha trafegam pela rede sem criptografia facilitando assim eventuais infortúnios como a utilização de analisadores de tráfego. Normalmente nos casos onde a autenticação é necessária se emprega servidores de FTP criptografados, sendo o Security Shell - SSH um dos mais populares.

Quando um cliente começa a negociar uma conexão com um servidor FTP, uma porta é escolhida e enviada para posterior conexão. O servidor, por sua vez, recebe a requisição pela porta padrão 20. A resposta do servidor é enviada pela porta 21 endereçada pela porta escolhida pelo cliente. A utilização do conceito de portas permite desta forma, que um mesmo servidor receba várias requisições pois a resposta é endereçada à diferentes portas escolhidas por cada cliente.

Page 125: Analista de Sistema Operacional

CBPF-NT-004/2000

________________________________________________________________________________________________ 16/19 04/04/01 Protocolos TCP/IP

6.6.2. Trivial File Transfer Protocol - TFTP

Este protocolo é utilizado principalmente para transferir arquivos de configuração ou mesmo do sistema operacional entre um computador e um equipamento, roteadores, comutadores, bridges, impressoras, etc. A aplicação também é do tipo cliente/servidor sendo normalmente o equipamento o cliente e o computador o servidor.

Ao invés de TCP, este protocolo utiliza UDP pois apresenta a possibilidade de acesso, normalmente para configuração, à equipamentos importantes em situações críticas como por exemplo quando um roteador fica inacessível por não suportar mais conexões TCP no caso de um ataque externo.

Servidores de TFTP não possuem autenticação sendo normalmente utilizados através de uma conexão direta na porta serial ou auxiliar do equipamento para garantir confiabilidade e segurança na transferência dos arquivos. Existem várias aplicações TFTP disponibilizadas de maneira compartilhada na Internet.

6.6.3. Telnet

Esta aplicação também do tipo cliente/servidor utiliza o protocolo TCP. É utilizada para conexão remota em computadores para execução de aplicações específicas muitas das vezes desenvolvidas pelo próprio usuário. Também usada para configuração e monitoramento remoto de equipamentos, como roteadores por exemplo. Como não transfere arquivos, é comum a utilização de aplicações FTP ou TFTP em conjunto.

Da mesma forma que o FTP, existe a necessidade de autenticação e portanto todos os problemas relativos a segurança também estão presentes. Da mesma forma, existem aplicações Telnet criptografadas compartilhadas na Internet.

6.6.4. Simple Network Management Protocol - SNMP

Este protocolo utiliza UDP para fazer gerência de equipamentos, sendo o protocolo base de todas as principais plataformas de gerenciamento, CiscoWorks - CISCO, HPOpenView - HP, SunNetManager - SUN, Transcend – 3COM, SCOTTY – TU Braunschweig, MRTG, dentre outras. Sua primeira versão possuía muitas falhas relativas a segurança e portanto era alvo certo dos hackers para invasão às redes. Apesar disto, sua utilização cresceu a ponto de se tornar o protocolo padrão das principais plataformas.

O funcionamento das aplicações está vinculado ao envio/recebimento periódico de mensagens, equipamentos/computadores respectivamente, que contém valores de parâmetros relevantes para monitoramento, análise e posterior configuração por parte dos equipamentos. Estas informações são

Page 126: Analista de Sistema Operacional

CBPF-NT-004/2000

________________________________________________________________________________________________ Protocolos TCP/IP 04/04/01 17/19

armazenadas em forma de base de dados chamada Management Information Base – MIB.

É possível configurar as aplicações para que enviem avisos através de e-mails, de sinais visuais e sonoros, Tc, aos gerentes de rede quando situações críticas ocorrerem, como por exemplo a mudança de estado de uma porta de um roteador, nível de tráfego fora dos limites, percentagem de processamento perto do limite, dentre outras.

6.7. Outros Protocolos e Aplicações

Existem vários outros protocolos que pertencem ao grupo TCP/IP dos quais podemos citar: SMTP, DNS, NFS, HTTP, RIP, Rlogin, X Windows, Packet Internet Groper – PING, Traceroute. Abordaremos rapidamente alguns deles.

Domain Name Server – DNS: também chamada de Name Service, esta aplicação relaciona endereços IP com os seus respectivos nomes atribuídos a dispositivos da rede.

Simple Mail Transfer Protocol – SMTP: este protocolo é utilizado nos serviços básicos de envio de mensagens.

Network File System – NFS: este sistema foi desenvolvido pela Sun Microsystems e permite que computadores possam “montar” discos ou parte deles (diretórios) de dispositivos remotos e operá-los como se fossem locais.

HyperText Transfer Protocol – HTTP: este protocolo é a base do ambiente World Wide Web que basicamente permite a leitura dinâmica e interativa de documentos constituídos de texto, imagens e som.

Routing Information Protocol – RIP: o conceito de roteamento é uma característica presente nos protocolos TCP/IP. O protocolo RIP é utilizado pelos dispositivos da rede, principalmente roteadores, para troca de informações de roteamento.

Dentre aqueles citados, é importante observar que os dois últimos, PING e Traceroute, são muito utilizados no monitoramento de conectividade entre dispositivos TCP/IP. No primeiro é possível o envio de pacotes em número e tamanho variáveis e o recebimento de sua respectiva estatística. O segundo revela o caminho percorrido por um pacote entre os dispositivos origem e destino parametrizado pelo tempo de resposta.

7. Conclusão

TCP/IP não é um protocolo único, é uma coleção de protocolos com arquitetura distribuída em 4 camadas que se distribuem sobre as camadas do modelo OSI: aplicação, host-host, rede e física.

Page 127: Analista de Sistema Operacional

CBPF-NT-004/2000

________________________________________________________________________________________________ 18/19 04/04/01 Protocolos TCP/IP

A camada física não é descrita na arquitetura TCP/IP apesar de ser a base para a comunicação entre a aplicação e a rede. O protocolo IP é a base da arquitetura pois atribui endereços lógicos aos dispositivos e às redes e assim consegue definir o caminho para levar os pacotes da origem ao destino.

TCP e UDP são protocolos da camada de transporte e tem como função principal a entrega de dados (segmentos) aos dispositivos destinos. O TCP é um protocolo orientado à conexão e assim garante que os dados cheguem na ordem certa ao seu destino. O UDP ao contrário, é não orientado a conexão e não garante a chegada dos dados ao destino.

Existem vários outros protocolos e aplicações que utilizam conexões TCP/IP e UDP/IP, e que não foram abordados aqui por simplicidade apenas.

A importância do conjunto de protocolos TCP/IP está totalmente ligada ao sucesso da Internet. Estes protocolos, apesar de suas limitações em termos de roteamento, cada vez mais, estão se tornando a base de aplicações que são disponibilizadas e necessárias à Internet.

O sucesso deste conjunto de protocolos implica inclusive no sucesso ou não da aplicação de outras tecnologias de comunicação. Atualmente podemos citar a tecnologia ATM como sendo uma das tecnologias que necessitam de artifícios de software para suportar aplicações IP.

O grande e crescente número de aplicações IP garante uma sobrevida ainda sem previsão de término à este conjunto de protocolos que já entraram para a história das comunicações. Atualmente, “falar TCP/IP” é condição básica para que um dispositivo entre na grande rede.

Page 128: Analista de Sistema Operacional

Soluções de alta disponibilidade

Todas as grandes empresas estão atualmente sob crescente pressão para manterem os seus sistemas a funcionar de modo a disponibilizarem os seus dados e serviços continuamente. Assim, sendo os padrões de exigência para a disponibilidade cada vez mais elevados, a solução passa por projetar sistemas de armazenamento e servidores altamente disponíveis e quase à prova de balas contra a inatividade não planeada.

A fim de atingir os mais altos níveis de disponibilidade, uma empresa tem que implementar uma solução completa que cubra todos os possíveis pontos de falha. Mas quais são as opções disponíveis para criar uma solução de alta disponibilidade?

Podem ver no gráfico as principais soluções para as três áreas a ser abordadas, armazenamento, serviços e redes:

Page 129: Analista de Sistema Operacional

Sistemas de gerenciamento de rede

As redes de computadores foram projetadas, inicialmente, como um

mecanismo para permitir o compartilhamento de recursos caros, tais como impressoras,

modems de alta velocidade, etc, existindo apenas em ambientes acadêmicos,

governamentais (principalmente em organizações militares) e em empresas de grande

porte. Entretanto, a evolução das tecnologias de redes aliada à grande redução de custos

dos recursos computacionais, motivou a proliferação das redes de computadores por

todos os segmentos da sociedade. Além disso, houve uma drástica mudança nos

serviços oferecidos, pois além do compartilhamento de recursos, novos serviços, tais

como correio eletrônico, transferência de arquivos, WWW, aplicações multimídia, etc

foram acrescentados, aumentando a complexidade das redes. Não bastassem esses fatos,

o mundo da interconexão de sistemas computacionais ainda tem que conviver com a

grande heterogeneidade dos padrões de redes, sistemas operacionais, equipamentos, etc.

Nesse contexto, onde percebe-se que cada vez é mais rápido o crescimento da

complexidade e heterogeneidade das redes de computadores, surge a necessidade de

buscar uma maneira consistente de realizar o gerenciamento de redes para, com isso,

manter toda a estrutura da rede funcionando de forma suave e atendendo às

necessidades de seus usuários e às expectativas de seus administradores.

No que se refere a gerência de redes, a proposta desse documento é apresentar

de forma sucinta alguns conceitos básicos relacionados à área a fim de oferecer uma

fundamentação para o estudo dos protocolos de gerência. Também será apresentada a

mais recente tendência no gerenciamento de redes, o Java Management.

Gerenciamento de Redes

Conceito

O gerenciamento de redes pode ser entendido como o processo de controlar uma rede de

computadores de tal modo que seja possível maximizar sua eficiência e produtividade.

Tal processo compreende um conjunto de funções integradas que podem estar em uma

Page 130: Analista de Sistema Operacional

máquina ou espalhados por milhares de quilômetros, em diferentes organizações e

residindo em máquinas distintas. Aqui, é importante observar que com estas funções

pode-se controlar uma rede de computadores e seus serviços, provendo mecanismos de

monitoração, análise e controle dos dispositivos e recursos da rede.

Metas

As principais metas do gerenciamento de redes são:

• Redução dos custos operacionais da rede

• Redução do congestionamento da rede

• Aumento da flexibilidade de operação e integração

• Maior eficiência

• Facilidade de uso

• etc

Atividades

A gerência de redes, como já citado na sua definição, não pode ser vista como uma

atividade única, ou seja, deve ser observada como uma atividade que pode, além da

operação da rede, envolver inúmeras tarefas, como por exemplo:

• Controle de acesso à rede

• Disponibilidade e desempenho

• Documentação de configuração

• Gerência de mudanças

• Planejamento de capacidades

• Auxílio ao usuário

• Gerência de problemas

• Controle de inventário

• Etc.

É importante frisar, aqui, que a maior ou menor importância de algumas dessas tarefas

estará associada ao tamanho e à complexidade da rede.

Recursos gerenciados

Page 131: Analista de Sistema Operacional

O gerenciamento de redes de computadores envolve monitoração e controle de

diferentes elementos de hardware e software, dentre os quais podem ser citados:

• Componentes dos computadores, tais como dispositivos de armazenamentos,

impressoras, etc

• Componentes de interconexão e conectividade, tais como roteadores, hubs,

switches, etc

• Sistemas operacionais, tais como Windows NT, Netware, etc

• Softwares de aplicação e ferramentas de desenvolvimento

• Etc

Terminologia

Antes de iniciar o estudo sobre gerenciamento de redes, faz-se necessária a apresentação

de alguns conceitos básicos relacionados à área, os quais servirão de base para a

compreensão da descrição dos protocolos de gerência. Tais conceitos são apresentados a

seguir.

Polling e Comunicação de Eventos

A informação que é útil para o monitoramento da rede é coletada e armazenada pelos

agentes, e disponibilizada para um ou muitos sistemas de gerenciamento. Duas técnicas

são usadas para disponibilizar a informação do agente, que servirá para o

gerenciamento: polling e comunicação de eventos. Polling é uma interação de

solicitações/respostas entre gerente e agente. O gerente pode questionar qualquer agente

( para o qual ele tem autorização ) e requisitar os valores de vários elementos de

informação; os agentes respondem com informações de sua MIB.

MIB

A base de informação gerencial (MIB - Management Information Base) é o nome

conceitual para a informação de gerenciamento, incluindo os objetos gerenciados e seus

atributos, operações e notificações. Pode-se também considerar as informações para a

configuração do sistema como também pertencentes à MIB.

Objeto Gerenciado

Page 132: Analista de Sistema Operacional

Um objeto gerenciado representa um recurso sujeito ao gerenciamento, isto é, que pode

ser gerenciado. Ele é definido em termos de seus atributos, das operações a que pode ser

submetido, das notificações que pode emitir e de seus relacionamentos com outros

objetos gerenciados. O conjunto de objetos gerenciados, juntamente com seus atributos,

operações e notificações, constituem a MIB.

Agentes

Os agentes são entidades que fazem a interface com os dispositivos a serem

gerenciados. Eles incluem sistemas finais que suportam aplicações de usuários bem

como os nós que oferecem um serviço de comunicação, tais como processadores de

front-end, controladores de clusters, bridges e roteadores.

Gerente

O gerente é um agente que possui o NMA (network-managment application). O NMA

pode ser entendido como uma aplicação que inclui uma interface de operador para

permitir a um usuário autorizado gerenciar a rede.

ASN1

A Abstract Syntax Notation One é uma linguagem formal desenvolvida e padronizada

pelo CCITT (International Consultative Commitee on Telegraphy and Telephony;

X.208) e pela ISO (International Organization for Standardization; ISO 8824). ASN.1 é

importante por diversas razões. Primeiro, pode ser usada para definir sintaxes abstratas

de aplicações de dados. Além disso é usada para definir estruturas de aplicação e

protocolo de apresentação de unidades de dados (PDUs). E finalmente é usada para

definir a base de informação de gerência (MIB) tanto para sistemas de gerenciamento

SNMP (simple network managment procotocol) como OSI (open systems

interconnection).

Arquitetura

Na figura a seguir, apenas como ilustração, é apresentada uma arquitetura típica do

gerenciamento de redes, com as interações agente/gerente.

Page 133: Analista de Sistema Operacional

Sistema de gerenciamento de Redes

Um sistema de gerenciamento de redes é uma coleção de ferramentas de monitoração e

controle que é integrado no sentido de possuir:

• Uma única interface de operação com um conjunto de comandos potente, mas

amigável, para realizar a maioria das tarefas de gerenciamento de rede.

• Uma quantidade mínima de equipamentos separados. Isto é, a maioria dos

elementos de hardwares e softwares requeridos para o gerenciamento de rede

está incorporado dentro do equipamento do usuário.

De forma simplificada, pode-se dizer que um sistema de gerenciamento de redes contém

dois elementos: um gerente e vários agentes.

Modelos de Gerenciamento

Os modelos de gerenciamento diferenciam-se nos aspectos organizacionais no que se

refere à disposição dos gerentes na rede, bem como no grau da distribuição das funções

de gerência. Existem dois modelos adotados para gerência de redes: o Modelo Internet

e o Modelo OSI.

Modelo Internet

Page 134: Analista de Sistema Operacional

O modelo de gerenciamento Internet adota uma abordagem gerente/agente onde os

agentes mantêm informações sobre recursos e os gerentes requisitam essas informações

aos agentes.

O padrão Internet SMI (Structure of Management Information) especifica uma

metodologia para definição da informação de gerenciamento contida na MIB. O SMI

usa um subconjunto de tipos de dados ASN.1. A MIB define os elementos de

gerenciamento de informação como variáveis e tabelas de variáveis.

Modelo OSI

O gerenciamento no modelo OSI da ISO baseia-se na teoria da orientação a objetos.

Com isso, o sistema representa os recursos gerenciados através de entidades lógicas, as

quais recebem a denominação de objetos gerenciados.

O modelo OSI permite a delegação das funções de monitoração aos agentes. Contudo,

as funções de controle ainda ficam relegadas ao gerente, pois o conhecimento relativo à

tomada de decisões gerenciais não se adapta para ser codificado em classes de objeto,

ao contrário do conhecimento referente à monitoração, que é mais simples, geralmente

estático e periódico.

Existem cinco área funcionais no gerenciamento num ambiente OSI:

• Gerência de configuração (estado da rede)

• Gerência de desempenho (vazão e taxa de erros)

• Gerência de falhas (comportamento anormal)

• Gerência de contabilidade (consumo de recursos)

• Gerência de segurança (acesso)

Um dos aspectos a serem considerados no gerenciamento OSI é o fato de que tal

modelo gera agentes mais complexos de serem desenvolvidos, consumindo mais

recursos dos elementos de rede, enquanto economiza o uso da rede, devido a

minimização dos pedidos de informações (pollings) necessários para obter dados sobre

objetos gerenciados, livrando o gerente para tarefas mais "inteligentes".

Page 135: Analista de Sistema Operacional

Protocolos e Padrões de Gerenciamento

Os protocolos de gerenciamento de rede têm sido tradicionalmente implementados

como protocolos do nível de aplicação. E até recentemente, cada vendedor costumava

ter um método proprietário pelo qual seus agentes podiam se comunicar, o que levava a

existência de incompatibilidades entre os diversos "padrões".

A necessidade de uma representação padronizada foi sentida tanto pelo IAB (Internet

Activities Board) quanto pela ISO. Enquanto a ISO trabalhou lentamente na

especificação do seu padrão, o IAB saiu na frente com a proposta do SNMP em 1989,

como uma solução temporária para gerenciamento de redes TCP/IP. A ISO só lançou

seu padrão, chamado CMIP (Common Management Information Protocol), muito

tempo depois. Devido a sua aceitação, o SNMP tornou-se um padrão de "facto" na

indústria. Como conseqüência desse sucesso, o SNMPv2 (SNMP versão 2) foi proposto

em 1993. Em 1996, foi proposto o SNMPv3 que está em fase de aprovação.’

A seguir serão discutidos os mais importantes padrões e protocolos adotados para o

gerenciamento de redes.

SNMP

O protocolo SNMP (descrito nos RFCs 1155, 1157, 1212, 1213) foi projetado, em

meados dos anos 80, como uma resposta aos problemas de comunicação entre diversos

tipos de redes. A idéia básica por trás do SNMP era oferecer uma maneira facilmente

implementável e com baixo overhead para o gerenciamento de roteadores, servidores,

workstation e outros recursos de redes heterogêneas. No momento de sua concepção, a

meta era que ele fosse apenas uma solução provisória até que surgisse um melhor

projeto de protocolo para gerência de redes. Entretanto, nenhuma solução melhor

tornou-se disponível.

O SNMP é um protocolo do nível de aplicação da Arquitetura TCP/IP, operando

tipicamente sobre o UDP (User Datagram Protocol). Ele é considerado "simples"

porque os agentes requerem um software mínimo. Muito do poder de processamento de

armazenamento de dados reside no sistema de gerenciamento, enquanto um subconjunto

complementar dessas funções reside no sistema gerenciado.

Page 136: Analista de Sistema Operacional

O modelo de gerenciamento de rede usado pelo SNMP inclui os seguintes elementos-

chave:

• Estação de gerenciamento

• Agentes

• MIB

• Protocolo de gerenciamento da rede, com as seguintes capacidades:

� Habilitar a estação de gerenciamento a requisitar os valores dos

objetos no agente;

� Habilitar a estação de gerenciamento a configurar os valores dos

objetos no agente;

� Habilitar um agente a notificar a estação de gerenciamento sobre

eventos significativos.

Como consequência da exigência de simplicidade adotada no seu desenvolvimento, o

SNMP acabou deixando de tratar algumas características, o que fez com que ele tivesse

algumas deficiências. Dentre essas características, destacam-se:

• Suporte para a transferência eficiente de grandes blocos de dados

• Estratégias de gerenciamento de rede centralizado

• Segurança

SNMPv2

O SNMPv2 foi desenvolvido com base nas especificações do Secure SNMP e do SMP

(Simple Management Protocol) . Seu propósito era remover muitas das deficiências do

SNMP e aumentar sua aplicabilidade para incluir redes baseadas no modelo OSI bem

como no modelo TCP/IP. Contudo, só as duas primeiras deficiências citadas acima

foram solucionadas por esta versão.

SNMPv3

É uma versão do SNMP que apresenta uma proposta de solução para o problema de

Page 137: Analista de Sistema Operacional

segurança encontrado nas versões anteriores do protocolo. As propriedades de

segurança abordadas são:

• Autenticação

Permite a um agente verificar se uma solicitação está vindo de um

gerente autorizado e a integridade do seu conteúdo.

• Criptografar

Permite gerentes e agentes a criptografarem mensagens para evitar

invasão de terceiros

• Controle de Acesso

Torna possível configurar agentes para oferecerem diferentes níveis de

acesso a diferentes gerentes.

RMON

O protocolo SNMP não é adequado para ambientes de redes corporativas e constituídas

de diversas redes locais conectadas através de outra de longa distância. Esses enlaces de

rede de longa distância, por operarem a taxas de transmissão inferiores às LANs que a

interconectam, passam a ter grande parte da sua banda de transmissão ocupada para

informações de gerenciamento. Uma solução encontrada para dirimir este problema foi

o Remote MONitoring (RMON).

RMON é uma capacidade de gerenciamento remoto do SNMP. A especificação RMON

é uma definição de uma MIB. Seu objetivo, contudo, é definir padrões de monitoração e

interfaces para a comunicação entre agentes/gerentes SNMP.

RMON dá ao gerente da rede a habilidade para monitorar sub-redes como um todo ao

invés de apenas dispositivos individuais na sub-rede.

O protocolo RMON oferece suporte à implementação de um sistema de gerenciamento

distribuído. Nele fica atribuída aos diferentes elementos, tais como estações de trabalho,

Page 138: Analista de Sistema Operacional

hubs, switches ou roteadores, das redes locais remotas a função de monitorar

remotamente. Cada elemento RMON tem, então, como tarefas, coletar, analisar, tratar e

filtrar informações de gerenciamento da rede e apenas notificar à estação gerente os

eventos significativos e situações de erro. A figura a seguir ilustra a utilização do

RMON em uma rede.

No caso de existirem múltiplos gerentes, cada elemento RMON deve determinar quais

informações de gerenciamento devem ser encaminhados para cada gerente.

Sendo assim, os objetivos do protocolo RMON são:

• Reduzir a quantidade de informações trocadas entre a rede local gerenciada e a

estação gerente conectada a uma rede local remota.

• Possibilitar o gerenciamento contínuo de segmentos de redes locais, mesmo

quando a comunicação entre o elemento RMON e a estação gerente estiver,

temporariamente, interrompida.

• Permitir o gerenciamento pró-ativo da rede, diagnosticando e registrando

eventos que possibilitem detectar o mau funcionamento e prever falhas que

interrompam sua operação.

• Detectar, registrar e informar à estação gerente condições de erro e eventos

significativos da rede.

• Enviar informações de gerenciamento para múltiplas estações gerentes,

permitindo, no caso de situações críticas de operação da rede gerenciada, que a

Page 139: Analista de Sistema Operacional

causa da falha ou mau funcionamento da rede possa ser diagnosticada a partir de

mais de uma estação gerente.

Dois padrões básicos de protocolo RMON são especificados: RMON1 e RMON2,

funcionalmente complementares.

RMON1

O RMON1 opera somente na camada Media Access Control (MAC) oferecendo

recursos ao administrador da rede para monitorar o tráfego e coletar informações e

estatísticas da operação de um segmento de rede local, além de realizar o diagnóstico

remoto de falhas e erros ocorridos no segmento de rede a partir de funcionalidades de

um analisador de protocolo suportadas pelo correspondente elemento RMON.

Porém, o fato do RMON1 só trabalhar na camada MAC, significa que este somente

apresenta estatísticas para tráfego agregado – porém não apresenta estatísticas para

camadas diferentes de várias pilhas de protocolos (ex. IP, FTP, IPX). Isto também

significa que, por não serem capazes de monitorar a camada de rede, os dispositivos

RMON1 não distinguem o tráfego originado através de um roteador, o que é uma

grande deficiência.

RMON2

O RMON2, por sua vez, opera no nível da camada de rede e camadas superiores,

complementando portanto o RMON1, possibilitando coletar informações estatísticas e

monitorar a comunicação fim-a-fim e o tráfego gerado por diferentes tipos de aplicação.

A figura a seguir ilustra esta diferença.

Page 140: Analista de Sistema Operacional

Proxies

O uso de SNMP requer que todos os agentes, bem como as estações de gerência,

suportem UDP e IP, o que limita o gerenciamento direto de dispositivos e exclui outros,

tais como bridges e modems, que não suportam nenhuma parte da pilha de protocolos

do TCP/IP. Além disso, existem inúmeros pequenos sistemas (PCs, workstations,

controladores programáveis ) que implementam TCP/IP para suportar suas aplicações,

mas para os quais não é desejável adicionar o peso do SNMP.

Para acomodar dispositivos que não implementam SNMP, foi desenvolvido um

conceito de proxy. Neste esquema, um agente SNMP atua como um proxy para um ou

mais dispositivos, isto é o agente SNMP atua a favor dos dispositivos sob o proxy.

CMIP

O CMIP é o protocolo para gerenciamento de redes definido pelo modelo OSI. O CMIP

especifica os elementos de protocolo que são usados para prover os serviços de

operação e notificação definidos pelo CMIS. É implementado num modelo orientado a

objetos e baseado em eventos. Destina-se ao gerenciamento de diferentes níveis do

modelo OSI, inclusive o de aplicações. Devido à sua complexidade, tem uso restrito.

CMIS

Page 141: Analista de Sistema Operacional

Define os serviços providos para o sistema de gerenciamento OSI. Estes serviços são

invocados pelos processos de gerenciamento para comunicação remota. É uma interface

de serviços de gerenciamento de redes OSI que monitora e controla redes heterogêneas.

CMOT

Criado com objetivo de viabilizar a convivência da arquitetura Internet e do protocolo

de gerenciamento OSI, o CMOT se baseia na estrutura de gerenciamento OSI e nos

modelos, serviços e protocolos desenvolvidos pela ISO para gerenciamento de redes. O

CMOT permite que a estrutura de gerenciamento OSI possa ser aplicada sobre os

objetos gerenciados de uma rede TCP/IP.

CORBA

CORBA (Common Object Request Broker Arquitecture) é um padrão atualmente em

desenvolvimento pelo OMG (Object Management Group) para fornecer mecanismos

pelos quais objetos podem, de forma transparente, fazer solicitações e receber respostas.

O CORBA ORB é uma estrutura que fornece interoperabilidade entre objetos,

construída em (possivelmente) linguagens diferentes, executando em (possivelmente)

máquinas diferentes em ambientes heterogêneos distribuídos.

Comparação: SNMP versus CMIP

No gerenciamento OSI, objetos gerenciados são vistos como entidades sofisticadas com

atributos, procedimentos associados e capacidades de notificação, e outras

características complexas associadas com a tecnologia orientada a objetos. Para manter

o SNMP simples, ele não foi projetado para trabalhar com tais conceitos sofisticados.

Na verdade, os objetos no SNMP não são objetos propriamente ditos do ponto de vista

da orientação a objetos; ao invés disso, objetos no SNMP são simplesmente variáveis

com poucas características, tais como tipo de dados e permissões de leitura e/ou escrita.

Em relação à MIB, as duas arquiteturas adotaram a abordagem orientada a objetos para

descrever e especificar as informações nela armazenadas. No caso Internet, são

definidos os objetos a serem armazenados na MIB. A ISO, por sua vez, especifica

algumas classes de objetos a serem empregadas pelos sistemas de gerenciamento e

fornece um guia de definição dos objetos gerenciados.)

Page 142: Analista de Sistema Operacional

A partir dos diversos aspectos apresentados sobre as arquiteturas de gerenciamento OSI

e Internet, pode-se concluir que:

• As duas arquiteturas apresentam modelos de gerenciamento similares

envolvendo elementos agentes e gerentes da rede, uma MIB e um protocolo de

aplicação responsável pelo transporte de operações e informações de

gerenciamento entre tais elementos agentes e gerente.

• No caso da arquitetura Internet, o elemento agente é muito mais simples. A sua

função básica é responder às operações de gerenciamento emitidas pelo gerente.

No caso OSI, o agente tanto responde às operações como também emite

notificações quaisquer de gerenciamento. Tais operações são mais complexas do

que as definidas para sistemas Internet. Vale salientar também que, tanto no OSI

como no SNMPv2 um elemento de rede pode exercer os papéis de agente e de

gerente simultaneamente, o que não acontece no SNMP.

• No que diz respeito aos protocolos de gerenciamento, o SNMP é um protocolo

não orientado à conexão que normalmente utiliza os serviços prestados pelo

UDP. O CMIP é um protocolo orientado à conexão executado sobre toda pilha

de protocolos OSI de gerenciamento. Dentro deste contexto, pode-se afirmar que

o sistema de gerenciamento OSI apresenta um nível de confiabilidade maior em

relação ao da Internet. Contudo, em determinadas situações de falhas, a

simplicidade do SNMP pode representar uma eficiência maior na solução do

problema ocorrido.

Estado da Arte

Gerenciamento de Redes Baseado em Java

A mais recente tendência no gerenciamento de redes é a utilização de sistemas de

gerenciamento baseados na tecnologia Java. Um sistema de gerenciamento baseado em

Java consiste de um browser gerenciador no NMS (Network Management System) e

uma máquina inteligente Java no agente. O browser gerente monitora e controla os

elementos de rede na rede. A máquina Java num elemento da rede executa as funções de

gerenciamento de um agente, bem como responde a perguntas do NMS. O browser

Page 143: Analista de Sistema Operacional

gerente e os processos dos agentes são programas de aplicações Java stand-alone que

são similares aos programas escritos em linguagens de mais alto nível disponíveis no

momento. A comunicação entre NMS e o agente é feita pelas classes Java.

A figura abaixo ilustra um setup experimental envolvendo máquinas rodando diferentes

sistemas operacionais tais como UNIX, Windows95, e Macintosh. O browser

gerenciador está rodando numa máquina UNIX. Estas máquinas estão conectadas

através uma rede Ethernet .

Arquitetura

A implementação de elementos de rede baseada em Java pode ser abordada em duas

maneiras. A primeira seria deixar a máquina virtual Java fazer virtualmente tudo num

elemento da rede tais como funções kernel, gerenciamento de processo, gerenciamento

de memória, chamadas de sistemas e interfaces de aplicação. A vantagem dessa

abordagem está no fato que a Sun Microsystems fez release do Sistema Operacional

chamado Kona, que é designado para dispositivos variando de pagers à redes de

computadores. A máquina Java como um todo pode ser uma implementação firmware

para o caso de um elemento de rede poder executar mais rapidamente suas funções.

Outra abordagem poderia ser aquela em que a máquina Java é um módulo de software

add-on que é adicionado ao kernel proprietário do fabricante. Neste caso, a máquina

Java poderia ser um ou mais processos sob o kernel que tem threads para transportar

várias funções de gerenciamento. Todos estes processos interagem com o sistema de

Page 144: Analista de Sistema Operacional

hardware usando a chamada de sistema e métodos nativos fornecidos pelo JLE (Java

Language Environment).

Java Dynamic Management Kit 2.0 (DMK)

Uma das consequências da análise do Java como ferramenta para gerência de redes, foi

o desenvolvimento de alguns produtos baseados nessa linguagem, dentre os quais pode

ser destacado o Java DMK.

O Java DMK é uma ferramenta universal de agentes Java que permite o rápido

desenvolvimento de agentes Java autônomos para sistemas, aplicações e dispositivos de

rede. Com sua estrutura de gerenciamento dinâmico e mecanismos para fornecer

serviços de gerenciamento ao longo da rede, o Java DMK vem abrir as portas para um

novo tipo de aplicações suaves e flexíveis de gerenciamento, que podem ser criadas,

distribuídas, melhoradas ou removidas em tempo real.

Comparação: SNMP versus Java

O gerenciamento de redes baseado no SNMP consiste de um programa de aplicação,

SNMP daemon e um módulo de User Datagram Protocol - UDP para transportar as

funções de gerenciamento. As mensagens entre o gerente e os agentes estão na forma de

SNMP PDU que concorda com a sintax ANS.1 e codificação BER.

O sistema Java consiste de browser e máquina Java para transportar funções de

gerenciamento. O sistema Java usa classes para comunicação entre o gerente e um

agente. A fundamental característica de segurança da tecnologia Java aperfeiçoa a

segurança do gerenciamento de rede. Uma desvantagem da abordagem Java é que pode

ser ineficiente quando usado com pequenas conexões TCP, cada uma para um pequeno

número de variáveis MIB. Mas também é verdade que quando aumenta o tamanho dos

dados recuperados, o TCP torna-se mais eficiente que o UDP. As maiores diferenças

entre os dois sistemas de gerenciamento estão listadas na tabela a seguir.

Page 145: Analista de Sistema Operacional
Page 146: Analista de Sistema Operacional

Nos anos 60, o principal setor estratégico americano, Department of Defense – DoD se interessou em um protocolo que estava sendo desenvolvido/utilizado pelas universidades para interligação dos seus sistemas computacionais e que utilizava a tecnologia de chaveamento de pacotes. O interesse do DoD estava no desejo de manter a comunicação entre os diversos sistemas espalhados pelo mundo, no caso de um desastre nuclear. O problema maior estava na compatibilidade entre os sistemas computacionais de diferentes fabricantes que possuíam diferentes sistemas operacionais, topologias e protocolos. A integração e compartilhamento dos dados passou a ser um problema de difícil resolução.

Foi atribuído assim à Advanced Research Projects Agency – ARPA a tarefa de encontrar uma solução para este problema de tratar com diferentes equipamentos e diferentes características computacionais. Foi feita então uma aliança entre universidades e fabricantes para o desenvolvimento de padrões de comunicação. Esta aliança especificou e construiu uma rede de teste de quatro nós, chamada ARPANET, e que acabou sendo a origem da Internet hoje.

No final dos anos 70, esta rede inicial evoluiu, teve seu protocolo principal desenvolvido e transformado na base para o TCP/IP (Transmition Control Protocol / Internet Protocol). A aceitação mundial do conjunto de protocolos TCP/IP deveu-se principalmente a versão UNIX de Berkeley que além de incluir estes protocolos, colocava-os em uma situação de domínio público, onde qualquer organização, através de sua equipe técnica poderia modificá-los e assim garantir seu desenvolvimento.

Dentre as várias organizações e comitês que participaram deste desenvolvimento e divulgação, podemos destacar Internet Engineering Task Force – IETF (http://www.ietf.org) cuja principal função atual é a manutenção e apoio aos padrões da Internet e TCP/IP principalmente através da série de documentos Request for Comments - RFC. Estes documentos descrevem as diversas tecnologias envolvidas e servem de base para as novas tecnologias que deverão manter a compatibilidade com as anteriores dentro do possível.

Em resumo, o maior trunfo do TCP/IP é o fato destes protocolos apresentarem a interoperabilidade de comunicação entre todos os tipos de hardware e todos os tipos de sistemas operacionais. Sendo assim, o impacto positivo da comunicação computacional aumenta com o número de tipos computadores que participam da grande rede Internet.

Arquitetura TCP/IP

Page 147: Analista de Sistema Operacional

2. Modelo de Referência ISO/OSI

Dentro deste cenário de grande variedade de sistemas operacionais, CPUs, interfaces de rede, tecnologias e várias outras variáveis, e a necessidade de interconexão entre os diversos sistemas computacionais, em 1977, a International Organization for Standardization – ISO, criou um sub-comitê para o desenvolvimento de padrões de comunicação para promover a interoperabilidade entre as diversas plataformas. Foi então desenvolvido o modelo de referência Open Systems Interconnection – OSI.

É importante observar que o modelo OSI é simplesmente um modelo que especifica as funções a serem implementadas pelos diversos fabricantes em suas redes. Este modelo não detalha como estas funções devem ser implementadas, deixando isto para que cada empresa/organização tenha liberdade para desenvolver.

O comitê ISO assumiu o método “dividir para conquistar”, dividindo o processo complexo de comunicação em pequenas sub-tarefas (camadas), de maneira que os problemas passem a ser mais fáceis de tratar e as sub-tarefas melhor otimizadas. O modelo ISO/OSI é constituído por sete camadas, descritas sucintamente a seguir de cima para baixo:

7 Aplicação Esta camada funciona como uma interface de ligação entre os processos de comunicação de rede e as

aplicações utilizadas pelo usuário.

6 Apresentação Aqui os dados são convertidos e garantidos em um formato universal.

5 Sessão Estabelece e encerra os enlaces de comunicação.

4 Transporte Efetua os processos de sequenciamento e, em alguns casos, confirmação de recebimento dos pacotes de dados.

3 Rede O roteamento dos dados através da rede é implementado aqui.

2 Enlace Aqui a informação é formatada em quadros (frames). Um quadro representa a exata estrutura dos dados

fisicamente transmitidos através do fio ou outro meio.

1 Física Define a conexão física entre o sistema computacional e a rede. Especifica o conector, a pinagem, níveis de tensão, dimensões físicas, características mecânicas e elétricas,

etc.

Page 148: Analista de Sistema Operacional

CBPF-NT-004/2000

________________________________________________________________________________________________ Protocolos TCP/IP 04/04/01 5/19

Cada camada se comunica com sua semelhante em outro computador. Quando a informação é passada de uma camada para outra inferior, um cabeçalho é adicionado aos dados para indicar de onde a informação vem e para onde vai. O bloco de cabeçalho+dados de uma camada é o dado da próxima camada. Observe a figura abaixo que esquematiza isto.

A unidade de informação muda de nome ao longo das camadas de maneira que podemos saber sobre qual camada se está referindo pelo nome destas unidades. A tabela abaixo relaciona os diversos nomes destas unidades de informação ao longo das camadas:

7 Aplicação Mensagem

4 Transporte Segmento

3 Rede Datagrama

2 Enlace Quadro/Frame

1 Física Bit

Antes do desenvolvimento do modelo de camadas ISO/OSI, o DoD definiu seu próprio modelo de rede conhecido como modelo DoD de rede ou também modelo Internet de rede. Posteriormente este modelo passou a ser conhecido como modelo de camadas TCP/IP, que será descrito a seguir.

Page 149: Analista de Sistema Operacional

CBPF-NT-004/2000

________________________________________________________________________________________________ 6/19 04/04/01 Protocolos TCP/IP

3. Modelo TCP/IP

O modelo de camadas ISO/OSI acabou se tornando apenas uma base para praticamente todos os protocolos desenvolvidos pela indústria. Cada desenvolvedor tem uma arquitetura que difere em detalhes as vezes fundamentais no seu desenvolvimento. Sendo assim, é de se esperar uma variação nas descrições do conjunto de protocolos TCP/IP. Apresentaremos a seguir a comparação entre duas possíveis interpretações, esquerda e direita do modelo base ISO/OSI ao centro:

Na figura acima, vemos que a tabela da esquerda apresenta os principais protocolos distribuídos pelas diversas camadas, enquanto que na tabela da direita as funções são o destaque.

Na tabela da esquerda vemos que o TCP/IP não faz distinção entre as camadas superiores. As três camadas superiores são estritamente equivalentes aos protocolos de processos da Internet. Os processos possuem o nome do próprio protocolo utilizado porém é importante não confundir o protocolo em si com a aplicação que geralmente apresenta uma interface com usuário amigável para utilização do protocolo.

No modelo ISO/OSI, a camada de transporte (4) é responsável pela liberação dos dados para o destino. No modelo Internet (TCP/IP) isto é feito pelos protocolos “ponto a ponto” TCP e UDP que serão descritos posteriormente.

Por fim, o protocolo IP é o responsável pela conexão entre os sistemas que estão se comunicando. Basicamente este protocolo se relaciona com a camada de rede (3) do modelo ISO/OSI. Este protocolo é o responsável principal do movimento da informação na rede. É nesta camada/protocolo que a informação é fragmentada no sistema fonte e reagrupada no sistema alvo. Cada um destes fragmentos podem ter caminhos diferentes pela rede de forma que os fragmentos podem chegar fora de ordem. Se, por exemplo, o

Page 150: Analista de Sistema Operacional

CBPF-NT-004/2000

________________________________________________________________________________________________ Protocolos TCP/IP 04/04/01 7/19

fragmento posterior chegar antes do anterior, o protocolo IP no sistema destino reagrupa os pacotes na seqüência correta.

Na tabela de direita consideramos o TCP/IP como sendo constituído por 4 camadas apenas. A camada superior, camada de aplicação/processo é responsável por permitir que aplicações possam se comunicar através de hardware e software de diferentes sistemas operacionais e plataformas. Muitas vezes este processo é chamado de cliente-servidor. A aplicação cliente em geral está em um equipamento mais simples e com uma boa interface com usuário. Esta aplicação envia requisições à aplicação servidor que normalmente está em uma plataforma mais robusta e que tem capacidade para atender várias requisições diferentes de clientes diferentes.

A camada que segue, camada de Transporte ou “Ponto a Ponto”, tem a função principal de começar e terminar uma conexão e ainda controlar o fluxo de dados e de efetuar processos de correção e verificação de erros.

A camada de rede é a responsável pelo roteamento. Comparativamente ela corresponde no modelo ISO/OSI a camada de Rede (3) e parte da camada Enlace (2). Esta camada é usada para atribuir endereço de rede (IP) ao sistema e rotear a informação para a rede correta. Tem ainda a função de ligação entre as camadas superiores e os protocolos de hardware. Em essência podemos afirmar que sem esta camada, as aplicações teriam que ser desenvolvidas para cada tipo de arquitetura de rede como por exemplo Ethernet ou Token Ring.

A primeira camada, camada Física, não é definida pelo TCP/IP, porém é nítida sua importância em relação à parte física da mídia de comunicação, de bits, de quadros, de endereços MAC, etc.

4. Endereçamento IP e Classes

Como visto anteriormente, a camada do protocolo IP ou protocolo Internet, define um endereço de identificação único e através deste endereço executa serviços de roteamento que basicamente definem o caminho disponível naquele momento para comunicação entre a fonte e o destino.

O protocolo Internet (IP) necessita da atribuição de um endereço Internet (endereço IP) organizado em 4 octetos (bytes). Estes octetos definem um único endereço dividido em uma parte que representa a rede a qual pertence o endereço, em alguns casos a subrede também, e por fim a representação particular daquele sistema na rede.

Alguns endereços possuem significado especial:

?? Endereço 0: Significa a própria rede ou sistema. O endereço 0.0.0.35 referencia a estação 35 da rede local. O endereço 127.0.0.0 referencia a estação em análise. O endereço

Page 151: Analista de Sistema Operacional

CBPF-NT-004/2000

________________________________________________________________________________________________ 8/19 04/04/01 Protocolos TCP/IP

152.84.40.0 referencia a subrede 40 inteira da rede local do CBPF que pode ser representada por 152.84.0.0.

?? Endereço 127: É conhecido como loopback e é utilizado em processos de diagnose. O endereço 127.0.0.1 é o próprio loopback da estação em análise.

?? Endereço 255: Este endereço é muito utilizado em mensagens broadcast e serviços de anúncio generalizados. Uma mensagem enviada para o endereço 152.84.255.255 irá atingir todos os 255 sistemas de cada uma das 255 subredes da rede local do CBPF.

A tabela a seguir relaciona os diversos aspectos relevantes na definição do endereço Internet: o número de sistemas possíveis, os primeiros bits do primeiro octeto e os seus possíveis valores. Os demais octetos podem assumir livremente os valores entre 0 e 255, sempre levando em conta aqueles de significado especial.

Classe 2n Hosts Bits IniciaisPrimeiro Octeto

A 24 167.772 0xxx 0-127 B 16 65.536 10xx 128-191 C 8 256 110x 192-223 D - - 1110 224-239 E - - 1111 240-255

Os endereços Classe A são usados para redes muito grandes normalmente ligada a funções educacionais e científicas. Os endereços Classe B são usados em redes muito grandes, normalmente atribuídas a instituições que possuíam um perfil disseminador de tecnologia e assim pudessem de alguma forma distribuir suas redes entre instituições e empresas contribuindo assim para o desenvolvimento de uma grande rede mundial. Os endereços Classe C são os mais difundidos pois permitem redes de 256 IP’s o que parece ser um número conveniente para gerenciamento e implantação de sistemas de informação. Os endereços Classe D são reservados para Multicast utilizado nas aplicações de Videoconferência, Multimídia, dentre outras, e por fim, os endereços Classe E são reservados para experimentação e desenvolvimento.

5. Subredes

A criação de subredes a partir de uma rede primária é um procedimento típico na área de redes. O objetivo desta segmentação é permitir uma melhor performance da rede em termos organizacionais, estruturais e funcionais.

Page 152: Analista de Sistema Operacional

CBPF-NT-004/2000

________________________________________________________________________________________________ Protocolos TCP/IP 04/04/01 9/19

Rede Sub Sistema 31 23 15 9 0

Máscara de Subrede 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0

31 23 15 9 255.255.255.252

A idéia básica é acrescentar alguns bits à identificador de rede do endereço Internet. Os endereços permitidos são aqueles formados pelos bits restantes do octeto. Veja figura anterior.

5.1. Máscara de Subredes

Conforme descrito na figura anterior, o identificador de redes e subredes, a máscara de subrede, também é composta por 4 octetos. A máscara é formada por bits 1 nos campos que caracterizam o endereço de rede, e bits 0 nos campos relativos ao host.

Considere uma Classe C com cada posição representada por um único bit de um endereço de 32bits:

R -> Rede H -> Host RRRRRRRR.RRRRRRRR.RRRRRRRR.HHHHHHHH

Se esta Classe C for dividida em 8 subredes com 32-2(rede e broadcast)=30 hosts em cada uma delas, a máscara será 255.255.255.224 ou ainda /27 e sua representação fica:

RRRRRRRR.RRRRRRRR.RRRRRRRR.RRRHHHHH 11111111.11111111.11111111.11100000

Em um outro exemplo queremos fazer 64 subredes com 4-2=2 hosts permitidos por subrede. Neste caso a máscara seria 255.255.255.252 ou ainda /30 com a seguinte representação:

RRRRRRRR.RRRRRRRR.RRRRRRRR.RRRRRRHH 11111111.11111111.11111111.11111100 O mesmo raciocínio pode ser empregado em uma Classe B ou Classe

A, mudando somente a relação entre bits 1 e bits 0, ou em outras palavras muda o octeto em análise. No caso de 2 subredes na Classe B teremos 255.255.128.0 ou /17 representadas por:

RRRRRRRR.RRRRRRRR.RHHHHHHH.HHHHHHHH 11111111.11111111.10000000.00000000

Vale ressaltar aqui uma operação simples implementada por todos algoritmos de roteamento que é o AND lógico entre a máscara de subrede e o

Page 153: Analista de Sistema Operacional

CBPF-NT-004/2000

________________________________________________________________________________________________ 10/19 04/04/01 Protocolos TCP/IP

endereço do host. Se o endereço tiver os mesmos bits 1 da máscara então este endereço pertence a subrede em análise e portanto o pacote pode ser enviado através de broadcast na subrede. Se diferir, então o pacote deve ser enviado ao gateway, pois certamente pertence a outra subrede.

6. Protocolos e Aplicações

Neste capítulo abordaremos os principais protocolos que compõem o conjunto TCP/IP de protocolos. Alguns destes protocolos são confundidos pela própria aplicação que os utiliza. Sendo assim, adiante haverá uma seção de Protocolos de Aplicação.

6.1. Protocolo Internet - IP

O protocolo Internet é definido na camada 3 do modelo ISO/OSI. Esta camada é responsável pelo endereçamento dos pacotes de informação dos dispositivos origem e destino e possível roteamento entre as respectivas redes, se diferentes. Este roteamento é executado através do IP.

Como visto anteriormente, o endereço IP é composto de 4 octetos, que são divididos em parte rede e parte dispositivo, chamados de identificadores de rede e de host, de acordo com o tipo de classe definido pelos primeiros bytes do primeiro octeto, e/ou subrede, definida pelo número de máscara.

Este protocolo, usando a parte rede do endereço ou identificador de rede, pode definir a melhor rota através de uma tabela de roteamento mantida e atualizada pelos roteadores.

Este protocolo recebe os dados da camada superior (transporte) na forma de segmentos. Ocorre então o processo de fragmentação e os conjuntos de dados passam a se chamar datagramas. Estes datagramas são então codificados para envio à camada inferior (física) para encaminhamento no meio físico.

Na tabela abaixo relacionamos as diversas partes (9) constituintes de um datagrama, o número de bits e função ou descrição.

O primeiro campo, Cabeçalho, contém informação sobre a versão do número IP (ipv4 ou ipv6) e o tipo de serviço (ToS), muito usado em aplicações que necessitem de Qualidade de Serviço (QoS).

O segundo campo, Comprimento, informa o comprimento do datagrama incluindo dados e cabeçalho.

O terceiro campo, Fragmentação, instrui ao protocolo, como reagrupar datagramas quando chegam após um processo de fragmentação muito comum em interfaces defeituosas e tráfego intenso.

Page 154: Analista de Sistema Operacional

CBPF-NT-004/2000

________________________________________________________________________________________________ Protocolos TCP/IP 04/04/01 11/19

O quarto campo, Time to Live – TTL, informa o número de roteadores que podem redirecionar o datagrama. O valor é decrementado até zero a cada roteador quando então o datagrama é descartado, impedindo a criação de loops e assim garantindo estabilidade ao processo de roteamento.

1 2 3 4 5 6 7 8 9

Bits 32 16 16 8 8 16 32 32 xxx

Des

criç

ão

Cab

eçal

ho

Co

mp

rim

ento

Fra

gm

enta

ção

TT

L

Pro

toco

lo T

CP

ou

UD

P

Ver

ific

ação

de

Err

os

En

der

eço

Fo

nte

En

der

eço

Des

tin

o

Dad

os

O quinto campo, informa qual protocolo deverá receber o datagrama na próxima camada. Se o valor deste campo for 6, TCP, se 7, UDP. Estes protocolos serão descritos posteriormente.

O sexto campo, Verificação de Erro, seleciona que processo será utilizado na detecção de erros: Cyclical Redundance Check – CRC ou Frame Check Sequence – FCS.

Os próximos campos, sétimo e oitavo, Endereço Fonte e Endereço Destino, 32 bits cada, caracterizam por completo toda informação sobre endereçamento necessária ao processo de roteamento.

O último campo contém os dados, a informação na realidade, e tem tamanho livre porém definido pelo tipo de rede sendo o MTU igual a 1500kbytes.

Todas as informações necessárias para que o IP possa se comunicar com o resto da rede estão distribuídas nestes campos, principalmente naqueles relativos ao endereçamento. É importante observar que a camada de rede utiliza estes endereços lógicos de 4x8bits, para definir as redes existentes e como conseguir obter informação delas. Entretanto, para que os dados cheguem aos hosts é necessário um outro tipo de endereço: endereço Media Access Control - MAC ou Ethernet.

O TCP/IP define um protocolo, ARP, que caracteriza e relação entre o endereço IP e o endereço MAC. Falaremos a seguir sobre este protocolo.

Page 155: Analista de Sistema Operacional

CBPF-NT-004/2000

________________________________________________________________________________________________ 12/19 04/04/01 Protocolos TCP/IP

6.2. Address Resolution Protocol - ARP

Na realidade, a troca de dados entre dispositivos IP é efetuada através do endereço MAC - Media Access Control, ou endereço Ethernet ou ainda endereço Físico. De maneira bem simplificada, podemos considerar o protocolo ARP como sendo um broadcast no segmento de rede perguntando qual é o endereço MAC do dispositivo que tem um certo IP.

Vamos considerar a figura abaixo através de dois exemplos típicos: comunicação no mesmo segmento de rede e em redes distintas.

Vamos considerar primeiramente uma aplicação no computador A enviando dados para o computador B, considere por simplicidade um serviço PING de A para B. O primeiro passo é determinar se A e B pertencem ao mesmo segmento de rede. Isto é feito através do simples algoritmo que compara o resultado de uma operação AND lógico entre os IP e a sua respectiva máscara: mesmo resultado mesma rede, resultados diferentes redes diferentes. No caso A e B são vizinhos de um mesmo segmento.

Na construção do datagrama, a aplicação sabe os endereços MAC e IP da fonte A e somente o endereço IP do destino B. Para descobrir o endereço MAC de B o protocolo ARP envia um broadcast a todos os dispositivos do segmento perguntando ao dono do IP B o seu endereço MAC. Por sua vez, o dispositivo dono do IP, envia também por broadcast, ou seja, para todos, o seu endereço MAC. Todos os dispositivos do segmento acrescentam na sua tabela ARP (IPxMAC), também chamada de proxycache ARP, este registro relativo ao B, que permanece durante um certo tempo. Finalmente, o dispositivo A envia o quadro (frame) destinado ao dispositivo B. Neste exemplo o mesmo quadro é enviado para B e a interface do roteador deste segmento, porém somente o dispositivo B irá abrir o quadro até a última camada pois somente ele tem o endereço MAC destino. Observe que se houvesse outros dispositivos no segmento, eles passariam a conhecer também o endereço MAC de B de maneira que se quiserem enviar algo à B posteriormente, não seria mais necessário um broadcast ARP.

Vamos agora considerar que a comunicação seja entre os dispositivos A e C. Primeiramente o dispositivo A determina que C pertence a outro

Page 156: Analista de Sistema Operacional

CBPF-NT-004/2000

________________________________________________________________________________________________ Protocolos TCP/IP 04/04/01 13/19

segmento através do algoritmo comparativo de operações AND. O dispositivo A então envia os dados para o gateway que é a interface do roteador. Para isto o protocolo ARP é utilizado para descobrir o endereço MAC da interface da mesma maneira que no caso anterior. Observe que o endereço MAC destino é do roteador porém o IP destino continua sendo do dispositivo C. Quando o roteador recebe os dados, ele procura pela rede à qual pertence o IP destino na sua tabela de roteamento e assim roteia para interface deste segmento. O roteador irá utilizar o protocolo ARP para determinar o endereço MAC do dispositivo C que será anexado ao cabeçalho da camada de enlace, como MAC destino e o seu próprio como MAC origem. É importante observar que os IPs origem (A) e destino (C) permanecem inalterados durante todo o processo. Quando o dispositivo C finalmente recebe a mensagem oriunda de A, o processo de volta é simplificado pois os diversos endereços MAC continuam nas tabelas dos dispositivos envolvidos (C, roteador e A).

Estes dois exemplos simples mostram o funcionamento e importância do protocolo ARP que na realidade só é usado para manter a tabela IP/MAC de cada dispositivo atualizada.

6.3. Internet Control Message Protocol - ICMP

O ICMP é um protocolo de mensagens de controle usado para informar outros dispositivos de importantes situações das quais podemos citar como exemplo: fluxo de mensagens maior que a capacidade de processamento de um dispositivo; parâmetro Time To Live – TTL; e mensagens de redirecionamento. Abordaremos rápida e separadamente cada um destes três exemplos.

Eventualmente um roteador pode estar recebendo mais informação do que pode processar, sendo assim ele passa a contar com controle de fluxo, enviando uma mensagem source quench para o dispositivo origem para que ele pare ou diminua o fluxo de dados. Esta mensagem é enviada pelo protocolo ICMP.

O segundo caso evolve o parâmetro TTL que basicamente é o número de hops (roteadores) total que uma informação pode percorrer. Ele é decrementado a cada hop e quando chega a zero, o roteador descarta o datagrama e envia uma mensagem à fonte informando que a informação não chegou ao seu destino, utilizando o ICMP.

O terceiro caso é a mensagem de redirecionamento ICMP, que é utilizada quando o roteador determina que um caminho melhor existe para o pacote que acabou de ser enviado assim mesmo. Neste caso a implementação do protocolo de roteamento pode definir um novo caminho de acordo com este melhor caminho. Alguns sistemas operacionais de roteamento não consideram esta mensagem e continuam enviando dados pelo pior caminho.

Page 157: Analista de Sistema Operacional

CBPF-NT-004/2000

________________________________________________________________________________________________ 14/19 04/04/01 Protocolos TCP/IP

Uma aplicação típica deste protocolo é o PING, muito utilizado para determinar se um determinado dispositivo está ativo em uma rede, já que esta aplicação testa o sistema de transporte do TCP/IP.

6.4. Transmission Control Protocol - TCP

O protocolo IP, camada de rede (3), envia dados para rede sem a preocupação de verificar a chegada dos respectivos datagramas. Os protocolos da camada acima, host-host ou transporte (4), especificamente TCP, definem a maneira para tratar datagramas perdidos ou corruptos. Além disto, TCP é responsável pela segurança na transmissão/chegada dos dados ao destino e também define todo o processo de início de conexão e multiplexação de múltiplos protocolos da camada de aplicação (7) em uma única conexão, otimizando assim a conexão múltipla de aplicações com o mesmo destino.

O protocolo TCP é orientado a conexão sendo isto claramente observado no processo de inicialização da conexão. O TCP aplica o algoritmo three-way handshake ou three-fold nesta inicialização. Este algoritmo pode ser comparado com o ato de telefonar onde em um primeiro momento um número é discado, posteriormente alguém atende dizendo “alô” e por fim a pessoa que ligou começa a falar, enviando dados.

Na realidade, o dispositivo fonte envia uma seqüência de números que iniciará o envio de segmentos (vide final da seção 2), início de uma conexão SYN. Sendo assim o dispositivo destino passa a conhecer esta seqüência. O dispositivo destino responde com sua própria segundai de números e portanto o dispositivo fonte passa por sua vez, a conhecer a seqüência do destino, viabilizando assim a conexão pois os dispositivos envolvidos, fonte e destino, sabem as respectivas seqüências numéricas. Esta segunda etapa é conhecida como acknowledgment ou ACK. Na terceira e última etapa, o dispositivo fonte emite o seu sinal ACK informando que começará a enviar dados.

Assim como o IP, o TCP precisa saber qual o protocolo de aplicação da última camada que receberá os dados. Isto é feito através da codificação das portas. Ao todo são 65.535 (64k) portas, sendo que de 0 à 1024 são portas definidas e portanto só podem ser usadas por aplicações que utilizem os respectivos protocolos. As portas de 1024 à 65535 são atribuídas dinamicamente. Existem exceções que podem ser ignoradas nesta discussão.

6.5. User Datagram Protocol - UDP

Existem situações em que o dispositivo origem não precisa da garantia de chegada dos dados no dispositivo destino, como exemplo podemos citar alguns tipos de Videoconferência. Nestes casos, o TCP é substituído pelo UDP que é um protocolo que não é orientado a conexão, ou seja, não necessita estabelecer uma conexão entre origem e destino antes de enviar os dados. Este protocolo não verifica nem se o dispositivo destino está on line.

Page 158: Analista de Sistema Operacional

CBPF-NT-004/2000

________________________________________________________________________________________________ Protocolos TCP/IP 04/04/01 15/19

Na realidade o protocolo UDP empacota os dados e os envia para camada inferior (rede 3) para que o protocolo IP dê prosseguimento ao envio dos dados. Estes pacotes, segmentos, apesar de serem numerados antes de serem enviados, não sofrem nenhuma verificação de chegada ao destino.

Assim como fizemos um paralelo entre TCP e o telefone, podemos comparar o UDP com o correio regular. Preparamos uma carta, envelopamos, selamos e colocamos no correio na esperança de que chegue ao seu destino.

Assim como o TCP, o UDP também é um protocolo da camada de transporte (4), porém diferentemente não gera mensagens ICMP.

6.6. Protocolos da Camada de Aplicação

Como foi visto anteriormente, o conjunto de protocolos TCP/IP estão distribuídos ao longo das camadas superiores se comparados com o modelo ISO/OSI. Dentre estes, existem muitos protocolos que atuam na última camada (Aplicação). Abordaremos a seguir os mais utilizados pela comunidade.

6.6.1. File Transfer Protocol - FTP

A aplicação FTP foi uma das primeiras aplicações na hoje chamada Internet. A base é o protocolo FTP que tem como principal função a transferência de arquivos entre dispositivos nos formatos ASCII e Binário. É uma aplicação do tipo cliente/servidor e em uma situação típica a aplicação cliente FTP utiliza o protocolo TCP para estabelecer uma conexão com o servidor remoto. Os servidores podem disponibilizar áreas só de leitura para download de arquivos compartilháveis ou leitura/escrita para áreas públicas sem restrição.

Normalmente estes servidores permitem conexão autenticada, login/senha, com usuários cadastrados para acesso em áreas do servidor restritas ou ainda usuário anonymous ou mesmo ftp, com senha livre, normalmente o e-mail, para posterior contato. É importante observar que neste processo de autenticação o login/senha trafegam pela rede sem criptografia facilitando assim eventuais infortúnios como a utilização de analisadores de tráfego. Normalmente nos casos onde a autenticação é necessária se emprega servidores de FTP criptografados, sendo o Security Shell - SSH um dos mais populares.

Quando um cliente começa a negociar uma conexão com um servidor FTP, uma porta é escolhida e enviada para posterior conexão. O servidor, por sua vez, recebe a requisição pela porta padrão 20. A resposta do servidor é enviada pela porta 21 endereçada pela porta escolhida pelo cliente. A utilização do conceito de portas permite desta forma, que um mesmo servidor receba várias requisições pois a resposta é endereçada à diferentes portas escolhidas por cada cliente.

Page 159: Analista de Sistema Operacional

CBPF-NT-004/2000

________________________________________________________________________________________________ 16/19 04/04/01 Protocolos TCP/IP

6.6.2. Trivial File Transfer Protocol - TFTP

Este protocolo é utilizado principalmente para transferir arquivos de configuração ou mesmo do sistema operacional entre um computador e um equipamento, roteadores, comutadores, bridges, impressoras, etc. A aplicação também é do tipo cliente/servidor sendo normalmente o equipamento o cliente e o computador o servidor.

Ao invés de TCP, este protocolo utiliza UDP pois apresenta a possibilidade de acesso, normalmente para configuração, à equipamentos importantes em situações críticas como por exemplo quando um roteador fica inacessível por não suportar mais conexões TCP no caso de um ataque externo.

Servidores de TFTP não possuem autenticação sendo normalmente utilizados através de uma conexão direta na porta serial ou auxiliar do equipamento para garantir confiabilidade e segurança na transferência dos arquivos. Existem várias aplicações TFTP disponibilizadas de maneira compartilhada na Internet.

6.6.3. Telnet

Esta aplicação também do tipo cliente/servidor utiliza o protocolo TCP. É utilizada para conexão remota em computadores para execução de aplicações específicas muitas das vezes desenvolvidas pelo próprio usuário. Também usada para configuração e monitoramento remoto de equipamentos, como roteadores por exemplo. Como não transfere arquivos, é comum a utilização de aplicações FTP ou TFTP em conjunto.

Da mesma forma que o FTP, existe a necessidade de autenticação e portanto todos os problemas relativos a segurança também estão presentes. Da mesma forma, existem aplicações Telnet criptografadas compartilhadas na Internet.

6.6.4. Simple Network Management Protocol - SNMP

Este protocolo utiliza UDP para fazer gerência de equipamentos, sendo o protocolo base de todas as principais plataformas de gerenciamento, CiscoWorks - CISCO, HPOpenView - HP, SunNetManager - SUN, Transcend – 3COM, SCOTTY – TU Braunschweig, MRTG, dentre outras. Sua primeira versão possuía muitas falhas relativas a segurança e portanto era alvo certo dos hackers para invasão às redes. Apesar disto, sua utilização cresceu a ponto de se tornar o protocolo padrão das principais plataformas.

O funcionamento das aplicações está vinculado ao envio/recebimento periódico de mensagens, equipamentos/computadores respectivamente, que contém valores de parâmetros relevantes para monitoramento, análise e posterior configuração por parte dos equipamentos. Estas informações são

Page 160: Analista de Sistema Operacional

CBPF-NT-004/2000

________________________________________________________________________________________________ Protocolos TCP/IP 04/04/01 17/19

armazenadas em forma de base de dados chamada Management Information Base – MIB.

É possível configurar as aplicações para que enviem avisos através de e-mails, de sinais visuais e sonoros, Tc, aos gerentes de rede quando situações críticas ocorrerem, como por exemplo a mudança de estado de uma porta de um roteador, nível de tráfego fora dos limites, percentagem de processamento perto do limite, dentre outras.

6.7. Outros Protocolos e Aplicações

Existem vários outros protocolos que pertencem ao grupo TCP/IP dos quais podemos citar: SMTP, DNS, NFS, HTTP, RIP, Rlogin, X Windows, Packet Internet Groper – PING, Traceroute. Abordaremos rapidamente alguns deles.

Domain Name Server – DNS: também chamada de Name Service, esta aplicação relaciona endereços IP com os seus respectivos nomes atribuídos a dispositivos da rede.

Simple Mail Transfer Protocol – SMTP: este protocolo é utilizado nos serviços básicos de envio de mensagens.

Network File System – NFS: este sistema foi desenvolvido pela Sun Microsystems e permite que computadores possam “montar” discos ou parte deles (diretórios) de dispositivos remotos e operá-los como se fossem locais.

HyperText Transfer Protocol – HTTP: este protocolo é a base do ambiente World Wide Web que basicamente permite a leitura dinâmica e interativa de documentos constituídos de texto, imagens e som.

Routing Information Protocol – RIP: o conceito de roteamento é uma característica presente nos protocolos TCP/IP. O protocolo RIP é utilizado pelos dispositivos da rede, principalmente roteadores, para troca de informações de roteamento.

Dentre aqueles citados, é importante observar que os dois últimos, PING e Traceroute, são muito utilizados no monitoramento de conectividade entre dispositivos TCP/IP. No primeiro é possível o envio de pacotes em número e tamanho variáveis e o recebimento de sua respectiva estatística. O segundo revela o caminho percorrido por um pacote entre os dispositivos origem e destino parametrizado pelo tempo de resposta.

7. Conclusão

TCP/IP não é um protocolo único, é uma coleção de protocolos com arquitetura distribuída em 4 camadas que se distribuem sobre as camadas do modelo OSI: aplicação, host-host, rede e física.

Page 161: Analista de Sistema Operacional

CBPF-NT-004/2000

________________________________________________________________________________________________ 18/19 04/04/01 Protocolos TCP/IP

A camada física não é descrita na arquitetura TCP/IP apesar de ser a base para a comunicação entre a aplicação e a rede. O protocolo IP é a base da arquitetura pois atribui endereços lógicos aos dispositivos e às redes e assim consegue definir o caminho para levar os pacotes da origem ao destino.

TCP e UDP são protocolos da camada de transporte e tem como função principal a entrega de dados (segmentos) aos dispositivos destinos. O TCP é um protocolo orientado à conexão e assim garante que os dados cheguem na ordem certa ao seu destino. O UDP ao contrário, é não orientado a conexão e não garante a chegada dos dados ao destino.

Existem vários outros protocolos e aplicações que utilizam conexões TCP/IP e UDP/IP, e que não foram abordados aqui por simplicidade apenas.

A importância do conjunto de protocolos TCP/IP está totalmente ligada ao sucesso da Internet. Estes protocolos, apesar de suas limitações em termos de roteamento, cada vez mais, estão se tornando a base de aplicações que são disponibilizadas e necessárias à Internet.

O sucesso deste conjunto de protocolos implica inclusive no sucesso ou não da aplicação de outras tecnologias de comunicação. Atualmente podemos citar a tecnologia ATM como sendo uma das tecnologias que necessitam de artifícios de software para suportar aplicações IP.

O grande e crescente número de aplicações IP garante uma sobrevida ainda sem previsão de término à este conjunto de protocolos que já entraram para a história das comunicações. Atualmente, “falar TCP/IP” é condição básica para que um dispositivo entre na grande rede.

Page 162: Analista de Sistema Operacional

FUNDAMENTOS DA COMUNICAÇÃO DE DADOS

O aprimoramento da tecnologia empregadas nos computadores e na comunicação

influenciaram profundamente no modo como os sistemas computacionais são organizados. O

conceito de “centro de computação” como sendo uma sala com um computador enorme, até o

qual as pessoas levam seus trabalhos para serem processados está obsoletas. O modelo antigo

da um único computador servindo todas as necessidade computacionais da organização foi

substituído por um outro modelo em que existe um grande número de computadores

autônomos, independentes, porém interconectados, executando tais tarefas. Esses sistemas são

chamados de redes computadores.

5.1 PRINCIPAIS CONFIGURAÇÕES

5.1.1 Sistemas Reativos, Tempo Real e Embutidos

5.1.1.1 Sistemas Reativos

Um sistema reativo é responsável pela manutenção do seu relacionamento com o meio

externo. Os processos que compreendem os sistemas reativos alternam dois tipos de períodos:

um relativo à espera de um estímulo do meio e o outro, de reação a esse estímulo. O

comportamento dos sistemas reativos são geralmente “infinitos”: um processo em um sistema

reativo é geralmente intermitente, isto é, responde continuamente aos estímulos do meio.

Sistemas reativos nada mais são que sistemas interativos, ou seja, processos interagindo com

seu meio. A diferença fundamental entre esses os dois está no mecanismo de sincronismo

disponível. Enquanto que o meio e o processo estão sincronizados apenas nos sistema

interativos, nos reativos apenas o processo possui tal habilidade. Por exemplo, uma interface

homem-computador é um sistema interativo uma vez que o homem se propõe a esperar a

resposta da máquina a ser mostrada pela interface. Por outro lado, o sistema de desativação

nuclear é reativo.

Page 163: Analista de Sistema Operacional

Portanto, ao contrário do que ocorre nos sistemas interativos, o processo é inteiramente

responsável pelo sincronismo do meio em que está inserido. Temos dois tipos de

sincronização:

- Sincronização por estímulo: o processo sempre é capaz de reagir a estímulos externos

(do meio)

- Sincronização por resposta: a resposta do processo sincroniza de acordo com o meio,

isto é, o tempo decorrido entre um estímulo e a resposta a esse estímulo é tão pequeno

(quando comparado à dinâmica do meio) que o meio ainda recebe essa resposta.

5.1.1.2 Sistemas em Tempo-Real e Sistemas Embutidos

A partir da definição acima, processamentos reativos nada mais são que processamentos em

tempo-real. A diferença entre esses dois tipo de processamentos está no foco de cada um

deles. Em sistemas em tempo real o processamento tem seu foco está no tempo: o maior

objetivo desses sistemas é projetar o processamento de modo a cumprir as restrições de tempo.

Quando falamos em sistemas reativos, espera-se uma abordagem do ponto de vista mais

lógico: mesmo que processamentos reativos tenham restrições de tempo, a importância maior

se restringe ao comportamento do processo. O sistemas reativos contempla dois estágios de

desenvolvimento de sistemas temporizados. Primeiramente, negligencia-se o tempo do

processamento e focaliza-se em assegurar a coesão das suas propriedades qualitativas. Nesse

caso, o tempo é tratado como uma variável discreta. Em segunda instância, dada uma

particular implementação para o processo, é feita uma análise quantitativa do tempo e este é,

então, tratado como uma variável contínua.

Ao caracterizar um sistema reativo como embutido, a ele é agregado uma forte restrição de

hardware para a sua implementação. Os sistemas embutidos são tipicamente utilizados em

produtos eletrônicos em que o custo de hardware é geralmente a maior restrição (porém longe

de ser a única). Genericamente, sistemas embutidos são essencialmente sistemas híbridos, uma

vez que são conectados a sistemas com componentes de hardware analógicos, sensores ou

elementos mecatrônicos envolvidos em um domínio contínuo.

Page 164: Analista de Sistema Operacional

5.1.2 Sistemas Distribuídos

Um sistema distribuído consiste em um conjunto de computadores autônomos ligados por uma

rede de computadores e equipados com um software de sistema distribuído. Esse software

permite que computadores coordenem suas atividades e compartilhem os recursos do sistema

(hardware, software e dados). Os usuários devem perceber um único e simples sistema embora

seja implementado por muitos computadores em diferentes lugares.

Ocorre na literatura uma considerável confusão entre uma rede de computadores (network) e

um sistema distribuído (distributed system). A diferença chave está no fato de que em um

sistema distribuído, a existência de vários computadores autônomos é invisível para o usuário;

ele pode digitar um comando para executar um programa e este é executado. Cabe ao sistema

operacional selecionar o melhor processador, localizar e transportar todos os arquivos de

entrada desse processador e direcionar os resultados nos lugares apropriados.

Em outras palavras, o usuário de um sistema distribuído não tem consciência da existência de

múltiplos processadores, como se estes fossem um processador único virtual. A alocação de

jobs aos processadores e de arquivos para discos, a transferência de arquivos de onde eles são

gravados até onde serão utilizados e outras funções de sistema devem ser automáticas.

Em uma rede de computadores, os usuários devem explicitamente: efetuar o login na máquina,

ativar jobs remotamente, mover arquivos e geralmente manipular todo o gerenciamento da

rede pessoalmente. Em um sistema distribuído tudo é feito automaticamente pelo sistema, sem

o conhecimento dos usuários.

Na prática, um sistema distribuído é um software construído “por cima” de uma rede de

computadores. O software lhe proporciona elevada coesão e transparência. Portanto, a

diferença entre esses dois sistemas está no software (especificamente no sistema operacional)

e não no hardware.

Exemplos de sistema distribuídos:

- UNIX distribuído (4BSD – Universidade de Berkley)

- Sistemas utilizados por companhias aéreas para reserva e emissão de bilhetes

Page 165: Analista de Sistema Operacional

- Rede bancária de caixas eletrônicos

5.1.2.1 Qualidades dos sistemas distribuídos/redes de computadores

As empresas possuem um grande número de computadores operando, geralmente em locais

apartados. Por exemplo, uma companhia com várias fábricas mantém pelo menos um

computador em cada uma delas. Inicialmente, cada computador trabalhava isoladamente dos

demais, mas em um certo momento a administração decidiu conectá-los para haver uma

integração de informações de cada das unidades fabris.

Trata-se, portanto, de um compartilhamento de recursos (resource sharing) em que o

objetivo é fazer com que todos os programas, equipamentos e principalmente dados fiquem

disponíveis para qualquer integrante da rede, independentemente de sua localidade.

Um segundo objetivo é prover elevada confiabilidade ao sistema, uma vez que possui várias

alternativas de suprimento. Por exemplo, todos os arquivos podem estar armazenadas em 2 ou

mais máquinas, de forma que se uma tornar-se não disponível (por falha de hardware), as

outras cópias podem ser utilizadas. Ademais, pelo fato de existirem múltiplos CPUs, se um

deixa de funcionar, os outros podem absorver seu processamento (apesar da redução de

performance).

Outra característica é a economia. As redes de computadores viabilizam a utilização de

computadores de pequeno porte em detrimento dos mainframes. Os PCs possuem uma melhor

relação preço/desempenho em relação aos de grande porte, uma vez que esses, apesar de mais

rápidos, são muitos caros. Por esse motivo designers de sistemas optaram por estruturar um

rede

pedido

resposta

Cliente Servidor Processo do servidor

Processo do cliente

Page 166: Analista de Sistema Operacional

modelo cliente-servidor, em que cada usuário (cliente) possui um computador (PC) e os

dados são armazenados em um ou mais servidores de arquivos.

Figura 1: Modelo Cliente-Servidor

No modelo cliente-servidor esquematizado na figura anterior, a comunicação geralmente é

feita através de mensagens de pedido do cliente para o servidor executar determinadas tarefas.

O servidor executa-as e as manda de volta ao como de resposta. Usualmente, tem-se um

grande número de clientes para um reduzido número de servidores.

Outra qualidade da rede de computadores é a capacidade de aumentar a performance do

sistema gradualmente, adicionando mais processadores (os mainframes centralizados, quando

o sistema satura, devem ser substituídos por outro maior capacidade, o que implica gastos

elevados e maiores complicações para os usuários). Com o modelo cliente-servidor, pode-se

adicionar mais servidores e clientes conforme a necessidade.

Por fim pode-se citar o fato de que as redes de computadores são um poderoso meio de

comunicação. Utilizando a rede, dois ou mais usuários podem escrever um relatório juntos,

mesmo estando apartados fisicamente; quando um documento online é alterado, os demais

usuários podem se interar dessa mudança imediatamente, ao invés de ter de esperar dias por

uma carta notificando-a.

Pode-se citar outros benefícios da redes:

� Acesso remoto a informações

- BBS: bulletin board systems

- Netnews: grupo de discussão em determinados assuntos

- WWW: world wide web

� Comunicação interpessoal

- e-mail

- videoconferência

� Entretenimento interativo

- jogos com múltiplos participantes em tempo real

Os itens seguintes irão tratar com mais detalhes as redes de computadores.

Page 167: Analista de Sistema Operacional

5.2 CLASSIFICAÇÃO DAS REDES

Não existe um critério de classificação que define o tipo de rede a ser utilizada, mas 2 (dois)

aspectos tornam-se bastante relevantes no momento da escolha: (1) a cobertura geográfica e

(2) a topologia de rede (mais ligada à tecnologia de transmissão empregada).

Quanto à cobertura geográfica, pode-se ter 3 tipos:

1. Redes Locais (Local Area Networks – LAN)

2. Redes Metropolitanas (Metropolitan Area Networks)

3. Redes de Longa Distância (Wide Area Networks)

Quanto à topologia de rede, pode-se ter dois tipos:

1. Redes em meio partilhado (Broadcast Network)

2. Redes ponto a ponto (Point-to-point Network)

Os itens 3 e 4 abordarão com mais detalhes esses tópicos.

5.2.1 Cobertura Geográfica

A tabela a seguir mostra a classificação de sistemas de múltiplos processadores arranjados de

acordo com seus tamanhos físicos:

Distância do

Interprocessador

Processadores localizados

no mesmo...

Exemplo

0,1 m Placa de circuito Máquina de fluxo de dados

1 m Sistema Multicompputadores

10 m Sala

Redes locais (LAN) 100 m Edifício

1 km Campus

10 km Cidade Redes Metropolitanas (MAN)

Page 168: Analista de Sistema Operacional

100 km País Redes de longa distância (WAN)

1 000 km Continente

10 000 km Planeta Internet

Tabela 1: Classificação das redes segundo a Cobertura Geográfica

5.2.1.1 Redes locais (LANs)

As Redes Locais, mais conhecidas como LANs (local area networks), são utilizadas de forma

ostensiva na interligação de PCs (personal computers) e de estações de trabalho em escritórios

de empresas e indústrias como forma de compartilhar recursos (por exemplo, impressoras) e

trocar informações.

As LANs diferenciam-se dos demais tipos de redes por 3 características: (1) tamanho, (2)

tecnologia de transmissão e (3) topologia.

1. Tamanho

As LANs possuem dimensões restritas; isto implica que o tempo de transmissão é

conhecido e, no pior caso, limitado. Esse fato possibilita utilizar configurações que não seriam

exequíveis em outro tipo de estrutura, além de simplificar a administração da rede.

2. Tecnologia de Transmissão

LANs utilizam um único cabo ao qual todos os equipamentos estão linkados. As LANs

convencionais transmitem a uma velocidade de 10 a 100 Mbps (megabits/segundo), possuem

em delay reduzido e produzem poucos erros.

3. Topologia

Existem várias topologias possíveis para uma rede local. A figura abaixo ilustra duas

delas:

computador

cabo

(a)

computador

(b)

Page 169: Analista de Sistema Operacional

Figura 2: topologias para LANs em meio partilhado:(a) barra. (b) anel

O item 4 irá tratar com mais detalhes as topologias de rede.

5.2.1.2 Redes Metropolitanas (MANs)

Uma rede metropolitana (metropolitan area network ou MAN) nada mais é que uma versão

ampliada de uma LAN e normalmente utiliza a mesma tecnologia. Ela deve cobrir um grupo

de escritórios corporativos próximos ou uma cidade, e pode ser privada ou pública.

Uma MAN suporta tanto dados como voz e pode inclusive estar ligada a uma rede de TV a

cabo. Possui apenas um ou dois cabos e não possui elementos de chaveamento que desviam

pacotes para uma das inúmeras potencial output lines, o que simplifica muito seu design.

O motivo pelo qual as MANs foram identificadas como uma categoria especial reside no fato

de ter sido criado um padrão para elas. Esse padrão é chamado DQDB (Distributed Queue

Dual Bus) ou IEEE 802.6. DQDB constitui-se de dois cabos unidirecionais aos quais todos os

computadores estão conectados (ver figura 2). Cada cabo possui um Head-end que é o

elemento que inicia a atividade de transmissão. Como ilustra a figura 2, informações

destinadas a computadores que estão à direita da estação remetente utilizam o barramento

superior; aquelas que vão para a esquerda utilizam o inferior.

Figura 3: Arquitetura das redes metropolitanas em DQDB

1 2 3 N . . .

Head-end

barramento A

barramento B

Direção de fluxo no barramento A

Direção de fluxo no barramento B

Page 170: Analista de Sistema Operacional

Um ponto chave das MANs é o meio partilhado para IEEE 802.6 (dois barramentos) ao qual

todos os terminais são linkados. Isso facilita muito seu design, quando comparado com os

outros tipos de redes.

5.2.1.3 Redes de Longa Distância (WANs)

Uma rede de longa distância (wide area network ou WAN) abrange uma extensa área,

geralmente um país ou um continente. A WAN possui uma série de computadores

denominados hosts os quais proporcionam atendimento, isto é, são fontes de recursos

(recuperação de informações, entrada remota de “jobs”, computação interativa, edição, etc.),

recebem e conduzem as requisições oriundas dos terminais e permitem aos usuários a

utilização de algum ou de todos os serviços disponíveis.

Os hosts estão conectados por uma sub-rede de comunicação (comunication subnet) ou,

abreviadamente, sub-rede. A função da sub-rede é transportar mensagens de host para host,

da mesma forma que o sistema de telefonia transporta a voz dos interlocutores. Separando os

aspectos de comunicação da rede (a sub-rede) dos aspectos de aplicação (os hosts), o design

da rede torna-se bastante simplificado.

Na maioria das WANs, a sub-rede consiste de 2 (dois) elementos: (a) linhas de transmissão e

(b) elementos de comutação. As linhas de transmissão, também conhecidas como circuitos,

canais ou troncos, transportam bits entre as máquinas.

Os elementos de comutação são computadores especializados utilizados para conectar duas ou

mais linhas de transmissão. Quando dados chegam numa linha de entrada, os elementos de

comutação escolhem a linha de saída que irá transmiti-los. Infelizmente não existe uma

terminologia padrão para esses computadores, podendo ser chamados de nós de comutação

de pacotes (pacote switching nodes), sistemas intermediários (intermediate systems), trocas

de comutação de dados (data switching exchanges). Arbitrariamente, será adotado o termo

genérico roteador (router).

Page 171: Analista de Sistema Operacional

Figura 4: Relacionamento entre hosts e a sub-rede

Como ilustra a figura 3, no modelo WAN cada host é geralmente conectado a uma LAN na

qual existe um roteador. Pode haver casos em que o host é diretamente ligado ao roteador.

O conjunto formado pelas linhas de transmissão e pelos roteadores denominamos sub-rede

(subnet).

Na maioria das WANs, a rede possui cabos e linhas telefônicas numerosos, sendo que cada um

desses conecta um par de roteadores. Se dois roteadores querem se comunicar e eles não são

interligados, eles o fazem indiretamente, via outros roteadores. Quando um pacote é enviado

de um roteador para outro por intermédio de um ou mais roteadores, ele é recebido

integralmente pelo(s) intermediário(s), armazenado enquanto a linha de saída estiver ocupada

e, então, repassado. A sub-rede que utiliza esse princípio é chamada sub-rede ponto-a-ponto,

store-and-foreward ou comutada por pacotes(packet-switched).Quase todas a WANs

possuem sub-rede store-and-foreward.

As redes com topologia ponto-a-ponto serão mais detalhadas no item 4.2.

5.3 TOPOLOGIAS DE REDE

5.3.1 Topologias em Meio Partilhado (“Broadcast Sys tems”)

As redes de meio partilhado possuem um único canal de comunicação que é compartilhado

por todas as máquinas (também denominadas computador, terminal e estação remota) a

elas pertencentes. Mensagens curtas (denominadas pacotes sob certas circunstâncias) enviadas

host

host

LAN

roteador sub-rede

Page 172: Analista de Sistema Operacional

por qualquer terminal são recebidas por todos os demais. Existe um campo na mensagem em

que se especifica seu destino. Cada terminal recebe a mensagem e checa esse campo: se a

mensagem for destinada a ele, ela é processada; se for destinada a outra máquina, ela é

simplesmente ignorada.

Sistemas em meio partilhado costumam possibilitar o endereçamento de uma mensagem para

todos os computadores, utilizando um código especial no campo endereço. Nessa ocasião

todas as máquinas processam a mensagem; este modo de operação é chamado

compartilhamento (broadcasting).

Os itens 5.3.1.1 e 5.3.1.2 descrevem dois tipos de redes de meio partilhado.

5.3.1.1 Barra (bus)

Em uma rede em barra, a cada instante,

apenas uma das máquinas é o master (ou

seja auqela à qual é dada a permissão de

transmitir) e às demais máquinas é

solicitada a desistência da transmissão. É

necessário haver um mecanismo que

administre e resolva conflitos quando duas

máquinas querem transmitir simultaneamente. Tal mecanismo pode ser centralizado ou

descentralizado.

O IEEE 802.3, vulgarmente conhecido como EthernetTM, é um exemplo de rede em barra

com controle descentralizado que opera a 10 ou 100 Mbps. Computadores em uma Ethernet

podem solicitar transmissão quando quiserem pois, se dois ou mais pedidos se confrontam,

cada computador aguarda um intervalo de tempo aleatório e tenta retransmitir.

5.3.1.2 Anel (ring)

Computador/Terminal/ Estação remota

cabo

Figura 5: Esquema de rede em BARRA

computador

Figura 6: Esquema de rede em ANEL

Page 173: Analista de Sistema Operacional

Em uma rede em anel, muitas das estações remotas conectadas ao anel não se comunicam com

um computador master. Ao invés disso, os dados a serem transmitidos são passados pelas

demais estações. Desse modo, a comunicação com um computador não fica interrompida caso

haja uma queda em sua linha, pois é possível atingí-lo pelo outro lado do anel. Uma

desvantagem pode residir no maior custo de linha envolvido no caso de os terminais estarem

geograficamente dispersos.

Nessa configuração, cada bit se propaga pela rede sem precisar aguardar o pacote ao qual

pertence. Normalmente, cada bit percorre todo o anel no tempo que este leva para transmitir

alguns bits, antes mesmo de todo o pacote ter sido transmitido.

Como toda rede em meio partilhado, algumas regras são necessárias para arbitrar acessos

simultâneos à rede-anel. O IEEE 802.5 é um exemplo de LAN em anel o qual opera de 4 a 16

Mbps.

5.3.2 Ponto a Ponto

Redes de conexão ponto-a-ponto consistem em uma série de conexões entre pares

individuais de máquinas. Para sair do seu terminal remetente (source) e chegar ao destinatário

(destination), o pacote (ou mensagem) desse tipo de rede deve primeiramente passar por uma

ou mais máquinas intermediárias. Geralmente, há múltiplos caminhos possíveis, de diferentes

comprimentos, por isso os algoritmos de roteamento desempenham um importante papel nas

redes ponto-a-ponto.

Via de regra, redes de pequenas dimensões e localizadas geograficamente costumam utilizar

redes de meio partilhado, enquanto que redes maiores geralmente são ponto-a-ponto.

5.3.2.1 Estrela

Neste tipo de sistema, todos os usuários comunicam-

se com um ponto central que tem o controle

sepervisor sobre o sistema. Os usuários comunicam-se

anfitrião terminais

Page 174: Analista de Sistema Operacional

entre si somente através desse processador central, denominado master ou anfitrião. O

movimento de dados é sempre de ou para o anfitrião. Se há a necessidade de comunicação

entre os procesadores remotos ou terminais, o anfitrião atua como o comutador central de

mensagens para passar os dados entre eles.

Figura 7: Esquema de rede em ESTRELA

Essa configuração facilita o controle da rede, sendo que a maioria dos sistemas de

compputação com capacidade de comunicação de dados possui software que exerça tal

função.

Page 175: Analista de Sistema Operacional

5.3.2.2 Grafo

Esse tipo de topologia também é chamada de

completa pois todos os elementos são

conectados um a um

5.3.2.3 Anel

Ver item 5.3.1.2

5.3.2.4 Árvore (ou Hierárquica)

Este tipo de estrutura é mais utilizada para

supervisionar aplicações de controle de

processos em real-time. Em tais sistemas é

utilizada uma hierarquia de computadores

para controle, sincronismo e registro dos

processos monitorados.

Pequenos sistemas baseados em sensores

proporcionam o controle do processo em tempo real, enquanto que a gravação dos eventos

ocorridos em cada processo é reportada a um nível superior, o qual, além de efetuar relatórios

para fins de contabilização, controle de estoque, etc., remete para um computador central que

Figura 9: Esquema de rede em ÁRVORE

computador

Figura 8: Esquema de rede em GRAFO

Page 176: Analista de Sistema Operacional

efetua, por exemplo, ao nível de corporação, controle e manipulação dos dados para maior

confiabilidade na atividade gerencial.

5.4 MODELOS DE TRANSFERÊNCIA DE DADOS

Existem três modalidades de comutação da informação que flui no interior de uma rede, desde

a fonte até o destino. São elas: (1) Comutação de mensagens, (2) Comutação de pacotes e (3)

Comutação de circuitos.

5.4.1 Comutação de Circuitos

Numa rede de comutação de circuitos, a tarefa dos nodos de comutação é estabelecer uma

conexão direta desde um terminal até o ponto de destino da informação por ele gerada. Uma

vez estabelecida a conexão, um caminho entre os extremos é delimitado e a informação é

transmitida sem interrupção da conexão até o final, e só então o circuito é descontentado e

habilitado para uso de outro par de usuários.

A rede pública telecomunicações opera na modalidade de comutação de circuitos. Em tais

sistemas, as chamadas são conduzidas de um terminal ou de um computador a outro através de

diversos centros de comutação. A interconexão de um terminal (ou computador) a outro pode

ser estabelecida através de diversas centrais, podendo haver trajetórias alternativas para

condução dos dados. Dessa maneira, pode ser estabelecida uma trajetória completamente

diferente entre um par de terminais (ou de computadores ou de terminal com computador) em

duas chamadas subsequentes.

Vale ressaltar que as transmissão de dados de um centro de comutação para outro pode ser

feita através de ondas eletromagnéticas (chamadas multiplexadas).

Uma propriedade importante da comutação de circuitos é a necessidade de se determinar o

caminho total pelo qual a informação irá ser transmitida ANTES do envio de qualquer dado. O

tempo de espera entre o final da discagem e o telefone começar a tocar pode ser de 10

Page 177: Analista de Sistema Operacional

segundos ou mais (para ligações internacionais ou de longa distância). Durante esses intevalo

de tempo, o sistema está a procura de um caminho para a ligação atingir seu destino. Dizemos

que o sistema está executando seu setup para a dada ligação.

Note que antes mesmo da transmissão de dados se iniciar, o sinal da ligação deve propagar ao

longo de todo o caminho e ser reconhecido. Para várias aplicações computacionais (por

exemplo, autorização de transação de compra com cartão de crédito em lojas) um longo tempo

de setup é indesejado.

Devido ao fato de o caminho entre o par de terminais ser pré-estabelecido, uma vez que o

setup foi executado, o único atraso que os dados sofrem é o de propagação do sinal

eletromagnético (aproximadamente de 5 ms por 1000 km). Outra consequência é, uma vez

estabelecido o caminho, a ausência de perigo de congestionamento (ele pode ocorrer apenas

antes da ligação ser estabelecida devido à falta de capacidade de comutação).

5.4.2 Comutação de Mensagens

Nesse modo de comutação, nenhum caminho físico entre a origem e o destino da informação é

pré-estabelecido. Ao invés de a rede ficar ocupada durante toda a transmissão (como ocorre na

comutação de circuitos), quando o remetente possui um lote de dados a ser transmitido, este é

armazenados em uma estação próxima ao usuário (roteador) e posteriormente enviado, a alta

velocidade, ao seu destino. Cada bloco é recebido integralmente, inspecionado e então

retransmitido. A rede que utiliza essa técnica é chamada store-and-forward.

Essa forma de serviço permite, mais facilmente, a adição de uma série de características à

transmissão, tais como mudanças de velocidade e multiplexação de vários roteadores (estações

transmissoras) Além do mais, para tráfego intenso, esse sistema otimiza o uso dos meios de

transmissão de longa distância, às custas de um acréscimo nos custos dos comutadores.

Esse sistema é originário da telegrafia com fita de papel. As mensagens eram perfuradas em

dita de papel à medida que iam sendo recebidas e então armazenadas para posterior envio ao

destino. Nessa modalidade de operação, a capacidade requerida na linha de transmissão

(tronco) é ¼ do que seria exigido em comutação de circuitos.

Page 178: Analista de Sistema Operacional

Na comutação de mensagens não há limitação para o tamanho do lote (ou bloco), o que

significa que os roteadores, devem possuir discos capazes de armazenar tanto os pequenos

como os grandes lotes indistintamente, provocando um aumento do custo de armazenagem de

dados de cada roteador. Ademais, um único bloco pode obstruir uma linha de transmissão

entre roteadores por minutos. Para contornar esses problemas, inventou-se a comutação por

pacotes.

5.4.3 Comutação de Pacotes

1. Vantagens sobre as redes de Comutação de Mensagens

Em redes de comutação de pacotes, é estipulado um limite superior para o tamanho dos

blocos de dados, permitindo que esses pacotes sejam armazenados na memória principal

(RAM) do roteador e não mais em discos. Nessa modalidade cada pacote é transmitido como

se fosse uma mensagem individual, com a vantagem de que nenhum usuário pode

monopolizar a linha de transmissão por muito tempo (transmissão na ordem de milisegundos)

e também, as redes de comutação de pacotes mostram um bom desempenho em manipular

tráfico de pacotes interativos.

Outra vantagem desse tipo de rede sobre as de comutação de mensagens é o fato de

que um primeiro pacote pode ser transmitido para um segundo centro de comutação antes

mesmo de o segundo pacote ter sido transmitido integralmente para o primeiro centro de

comutação, o que reduz o delay e melhora o desempenho.

2. Vantagens sobre as redes de Comutação de Circuitos

A diferença básica entre essas duas modalidades é que a rede de comutação de

circuitos reserva, estaticamente e de forma antecipada, a frequência das ondas

eletromagnéticas em que os dados serão transmitidos, ao passo que a comutação de pacotes a

aloca e incrementa conforme a necessidade.

Page 179: Analista de Sistema Operacional

Com a comutação de circuitos, qualquer frequência que não está sendo utilizada é

simplesmente desperdiçada. Já na comutação de pacotes essa, seria aproveitada por uma

ligação qualquer, uma vez que os caminhos não são dedicados. Entretanto, esse fato pode

ocasionar uma intensificação do tráfico em um roteador, causando neste uma sobrecarga e

eventual perda de pacotes.

A comutação de circuitos é totalmente transparente. O remetente e o destinatário

podem utilizar qualquer método de bit rate, formato ou estruturação que desejarem. É essa

transparência que permite transmissão de voz, dados e faz coexistentes com o sistema de

telefonia.

Na comutação de pacotes, a linha de transmissão tem determinados os parâmetros

básicos, tais como: tamanho, velocidade e natureza dos dados.

Quanto a forma de cobrança, a comutação de pacotes baseia-se na quantidade de bits

(ou pacotes) transmitidos e o tempo de conexão. A de circuitos baseia-se apenas na distância e

tempo de transmissão, não no tráfico.

A tabela abaixo resume as diferenças entre as redes de comutação de pacotes e as de

comutação de circuitos.

Item Comutação de Circuito Comutação de Pacotes

Caminho de transmissão dedicado Sim Não

Frequência de transmissão (bandwidth

avaible) Fixa Dinâmica

Potencial desperdício de frequências de

transmissão Sim Não

Transmissão Store-and-forward Não Sim

Todo pacote percorre o mesmo caminho Sim Não

Setup de ligação/chamada Necessário Desnecessário

Quando uma obstrução pode ocorrer No momento do setup Em todo pacote

Cobrança ($) Por minuto Por pacote

Tabela 2: Comparação entre a comutação de pacotes e a de circuito.

Page 180: Analista de Sistema Operacional

TOPOLOGIA O termo topologia refere-se à distribuição ou layout físico dos computadores, cabos e outros componentes da rede.

A escolha de uma determinada topologia afeta: • o tipo de equipamento que será usado; • a capacidade desse equipamento; • o crescimento da rede; e • a maneira como esta será gerenciada.

As várias combinações de tipos de cabo, placas de rede, sistemas operacionais de rede e outros componentes, requerem distribuições diferentes. Uma topologia implica uma série de condições. Por exemplo, uma determinada topologia determina que tipo de cabo deverá ser usado, e como este será passando pelo chão e pelas paredes. Depende dela também o método de comunicação entre os computadores, o que tem grande influência sobre a rede.

ARQUITETURA CLIENTE/SERVIDOR O termo cliente/servidor refere-se ao conceito de dividir o trabalho de processamento de dados entre um computador

cliente e um computador servidor mais poderoso. Nessa arquitetura existem basicamente 2 componentes: servidores: computadores que provêm recursos para os usuários da rede; clientes: computadores que acessam os recursos que o servidor oferece. Esses recursos podem ser de hardware, com impressoras; ou de software, como um banco de dados ou uma página de internet. Um servidor pode ser dedicado, quando sua função é de apenas atender às requisições dos usuários da rede. Nesse modelo, as requisições são atendidas da maneira mais rápida possível, e a segurança das informações é garantida. Com o crescimento da rede, pode ser necessário o uso de mais de um servidor, dividindo as tarefas.

MODELO OSI

Modelo OSI Quando as primeiras redes surgiram, cada fabricante de computador utilizava uma arquitetura própria, o que

impedia que computadores diferentes pudessem ser conectados à mesma rede. O modelo OSI (Open Systens Interconnection) surgiu da necessidade de criação de uma arquitetura única e se tornou um padrão internacional, sendo usado pelos fabricantes nas especificações de seus produtos de rede. Ele descreve como os componentes (hardware e software) de rede devem funcionar em conjunto para garantir a comunicação. O modelo OSI se divide em 7 camadas. Cada camada possui funções, serviços e protocolos bem definidos, que trabalham com as camadas imediatamente acima e abaixo dela. Por exemplo: a camada Sessão deve se comunicar com as camadas Transporte e Apresentação. Cada camada executa um Serviço que prepara os dados para serem enviados à outra camada. A divisão entre elas é chamada de Interface. É através das interfaces que as camadas adjacentes se comunicam.

Camadas do Modelo Camada de Aplicação

A camada 7 representa os serviços de acesso à rede que suportam os aplicativos dos usuários, como programas de transferência de arquivos, banco de dados e e-mail.

A camada de Aplicação é responsável pelo acesso geral à rede, controle do fluxo de informações e recuperação de erros.

Page 181: Analista de Sistema Operacional

Camada de Apresentação

A camada 6 determina o formato usado para a troca de informações entre os computadores da rede. Pode-se pensar nela como a "tradutora" da rede.

No computador origem, essa camada traduz os dados recebidos da camada de Aplicação para um formato comum, intermediário. No computador destino, ela traduz os dados do formato comum para um formato que pode ser reconhecido pela camada de Aplicação.

As principais funções dessa camada são: conversão de protocolos, "tradução" de formatos, encriptação e compressão dos dados.

Camada de Sessão

Permite que duas aplicações em computadores diferentes usem uma conexão, chamada Sessão. A camada 5 executa funções, como a de segurança, necessárias para que as aplicações se comuniquem pela rede.

Essa camada implementa o controle de diálogo na comunicação, regulando quem transmite, quando e por quanto tempo. Também é a responsável pela sincronia durante uma transmissão, colocando "pontos de verificação" no fluxo de dados. Dessa forma, se houver uma falha na rede, apenas os dados posteriores ao último "ponto" serão retransmitidos.

Camada de Transporte

A camada 4 implementa um nível de conexão confiável abaixo da camada de Sessão, garantindo uma transmissão sem erros, na sequência correta e sem perdas ou duplicações.

A camada de Transporte executa o controle de fluxo, correção de erro e participa do processo de solução de problemas na transmissão e recepção dos pacotes.

Camada de Rede

A camada 3 é responsável pelo endereçamento das mensagens e tradução dos nomes e endereços lógicos em endereços físicos. É ela também que determina qual caminho será usado na transmissão, baseando-se nas condições da rede, prioridade nos serviços e outros fatores.

Camada de Enlace de Dados

O objetivo da camada 2 é detectar e, opcionalmente, corrigir erros que possam ocorrer na camada Física, transformando um canal de transmissão não-confiável em um canal

Page 182: Analista de Sistema Operacional

confiável. Para isso, divide os dados em pedaços menores, ou quadros, contendo informações para detecção de erros.

Outra função dessa camada é o controle de fluxo, que evita elacionamento Entre as Camadas

As camadas estão configuradas de tal maneira que cada uma parece estar se comunicando com a camada correspondente do outro computador. Essa comunicação virtual ou lógica

cria o conceito de Parceiros ou Peer.

Antes da informação ser transmitida de um computador para outro, ela é dividida em partes menores, os chamados Pacotes.

Cada pacote passa por todas as camadas, iniciando na mais alta até chegar na camada Física. Em cada uma delas, recebe um cabeçalho com informações de endereçamento e correção de erros relativos àquela camada. Ao chegar na camada Física, esse conjunto de informações (a original e os vários cabeçalhos) recebe o nome de Quadro. Quando chega ao computador destino, o Quadro segue o caminho inverso, ou seja, vai percorrendo as camadas da mais baixa até a mais alta. Cada camada retira o seu cabeçalho, verifica se as informações estão corretas e passa o pacote para a camada superior.

MODELO TCP/IP

Modelo TCP/IP

Transmission Control Protocol/Internet Protocol (TCP/IP) é um conjunto de protocolos projetado para redes de longas distâncias (WANs) e para comunicação entre computadores de diferentes tipos. Como quase todas as

redes o suportam, tornou-se o protocolo padrão usado na Internet. O TCP/IP é baseado em um modelo de 4 camadas: Aplicação, Transporte, Inter-Redes e Física. A camada Física é responsável por colocar e retirar quadros do cabo. A Inter-Redes é responsável pela transferência de dados desde a máquina origem até a de destino. Possui 3 protocolos:

• IP (Internet Protocol) é responsável pelo endereçamento e roteamento de pacotes entre máquinas e redes; • ARP (Address Resolution Protocol) é usado para descobrir os endereços físicos das máquinas que estão na

mesma rede; • ICMP (Internet Control Message Protocol) envia mensagens e relata erros na entrega de pacotes.

A camada de Transporte permite a comunicação entre 2 máquinas. Possui 2 protocolos: • TCP (Transmission Control Protocol) é orientado à conexão, e provê uma comunicação confiável para

aplicações que transferem grandes quantidades de informações e que precisam de confirmação do recebimento destas informações;

• UDP (User Datagram Protocol) provê uma comunicação não-orientada à conexão, e não garante a entrega das informações.

Na camada de Aplicação, os usuários executam aplicações que usam os serviços de rede. Algumas aplicações disponíveis nessa camada são:

• SMTP (Simple Mail Transfer Protocol) que envia e recebe mensagens de texto (e-mail); • WWW (World-Wide Web) que permite acesso à informações no formato hipertexto (internet);

Page 183: Analista de Sistema Operacional

• Ping verifica se uma determinada máquina está "on-line" e qual seu tempo de resposta; • DNS (Domain Name System) que "traduz" nomes de domínio (www.empresa.com.br) em endereços IPs

(200.123.456.789).

COMPARAÇÕES

Modelo OSI X Modelo TCP/IP

Pontos em comum: as camadas são independentes e têm funções bem definidas. Diferenças:

Modelo OSI Modelo TCP/IP

7 camadas 4 camadas

Modelo "de juri", apenas para referência

Modelo "de fato", é realmente usado

Conceitos de Serviço, Interfaces e Protocolos bem definidos.

Não faz distinção desses conceitos.

Criado antes dos protocolos Criado depois dos protocolos

ROTEADORES

Roteadores Em um ambiente constituído de vários segmentos de rede, é necessário um dispositivo que conheça os endereços de

cada segmento e determine o melhor caminho para o envio dos dados. Tal dispositivo é chamado de Roteador. Executam as seguintes funções:

• filtrar e isolar o tráfego; • conectar vários segmentos de rede.

O Roteador utiliza uma tabela interna para determinar o endereço de destino. Esta tabela contém as seguintes informações:

• todos os endereços de rede conhecidos; • como conectar em outras redes; • os possíveis caminhos para outros roteadores; • o "custo" do envio de dados por esses caminhos.

Page 184: Analista de Sistema Operacional

���������������� ������������������ � ������������������������������ ��������������������������������������������� � ��������������� � ���������������������������������� ������ �!����� �����"�������������� �#�����������������$ �������������������� �%��������������� ���������������� ���������������� ������������ �����������&������������������� �������� '(� �)� �� ���� ������������������*������������ � ����������� ������������+ ���,�����-������-��. ��/�01234567528393:3;345<����������������������=�����+�>�?� ����������������� �@8393:3;345AB789345���������� �������������������������� � ���� ������ ����C��� ������������� �������������������������������$ ���������� ���� �)������������ ��������������������������������� �������� $������������ '(������������ �)��"������=�������������D�������������� ������D���E!�FG��,E� �����!����������������F�G����������������/ ����D���������������������������������������*���������� ���������������� �,�����H �����+&�I����.&�J���=&�)��=&���� / �K�E!�FG��D�������������� ������ �G������� �@8393:3;345L427:MN1:345������������������������������ � � �������������������+ ��������������� �!����D���� �����G�O�F�%�O����������������������������� ������� � � �������� �-������-��. �� �501234567598PQ4R144S356756P6345��������������*������������� ��� ���������� ����������������������������� ����� �K�������� �D��������� ������������������������������*�����,������=���� ���� � ���� '������������ ��� � /����= � �������� ����������=������������� �T��� ���� ��������*�������� � ������ �����&��������������U�����?�)��� �&�V�� �� ����H����� � �5���������������� �

Page 185: Analista de Sistema Operacional

� ����������� ��������������� �������� ��������������������������������������������� ����������������������� ��������������� �������� ���� �!��" ��� �������� ������������������������������������#$���������� �!�������������� ������������� ��������� ���������� �����������%�� �����$������������������� �������������������#�� ��������������&�������������������������'��� �������$����#������( ��)� �������%�*���������� ������������������ ���������� ��+,-�.��������%��������������������������$���������� ����� ����������� ��/�������$�0������ �!������������������������������������������������������� �����1��������������������� �������������������%�� �����$�������������$�1�������������������*��������2#�� ��������������� ������������������*����������� �3��������"������ ������$�1������������������*������������� �0�����������������������#4��� �������%�����%� ����1����������� ������� �$������ ��%��������� ��*�����������������������������5���67�����������5������������'� ����������������67����� �������� (�%�����$�����������������8���� �9�� �����:��������������#� �����������������"�������� ������������� ����*���������� ��;<=����>� ������� ����������� �>���������������� ������������������������������������ ��������� ��$�1���������������������*��������������������������� ���� ����#$����� �������������������� ���������� �������������������������� �3 ����������5������6�������� ����� ������������������� �������������� �����������������'� ����������1�����������%������� ������� ��$�1������������ ��������� �����������( �6��� �����%������������������ ����5���� ������*������������������6?37 �@A+�-�B������$����!��C6)0�'!��C�D6(�$��� ���������������������������������8���������� ����������������������������� ���������������� �E���������������������1����FGHI��J�K�����L�� ��M �� ��NO�������$���������������������� �������������$������������� ��������� ��������������������������������������������������#P����QRR����� ������� ��B� ����������!��C6)0�%� �����������P�� ���������������� ��������������4������������������ �����������������������#�������������������������� �B�����������5���!��C6)0����S����I��%��"���������!��C�D6 �B��� ����������������� ��:�TU?�������������������������$��V�����TU!��" ���������������������$�� ��5���TUE������*������������������������������������������������������������� �������W�� P�' ��������0��*�( ��B�&�����������������%�� ����!��C6)0������ ���������������� �X�������������&���:����#P����� �����V����������� ����������� ���������������������%������� ����������� �

Page 186: Analista de Sistema Operacional

� ���������������� ��������������������������������������������������������� ������������� ����������������������� �������������������� �!������ ������ �"���#��������$!��%��������������&��� ��������'#���� ����� ����$���(���!� ����������$�������� )������!�*�������� ��$�������"��+!������)��,���� ��-�������� ������ ������+������'#��+���� &����!"����$���������.���������� ����������*�/!������+!&� ��$�&�����$�����������!� �� �� ���������������-��� ��&���������'012���3� �,������+!�-���� ����������� ������&� ��%��������������'#����3� �,����������������������!)�� ���'012����������3� �,��� ����������2��� ������������$�!��������� ��3� �,�4�5������� ������������!)�� �����������������"����6� � � ���������� )������7�8��!����$������������������!)�� ���7�(�*�������&� ������������� ���1�� �������1�����������!� ������$������� ���9 �����������������������!� &��������������+�!� &��� ������������ -!��������!����������:-���������������!�%���6� � ���$��������&����������0���������!��� �������'#����������������������� ����%��;<=>?@ABCD=EFGHIJI=K<=L?DMNOMPQ=R<=STUI=V������ �!���������������6�W#��������������������������!���������9!��� ����� ����������� ��������'#���� �����'0����� ���� ��&��� ������������!�)������#��������� ���������� � ����������� �� ����� ������.���������&�� ����������%�=XUTY=============Z[\]=FMO=HI=Y=======_a]\bcdefg\h=SBiNDjP=kY===lmnopgenacqercepg\cecsopgenacteocopa]ufugevwSBiNDjP=UJ===lmnopp]m_a]\bxymzho{\ham|]=�#�����������������������!�*� �����&�� ���� �� %����}=~iN~?~�D=T��==~P�M�D==}iD�~=U~QLTHI�=�9��������������������!����������������������0��/������� ������ �-��������!�*� ����������������+� ���%� ����� �� �����������6�W#��������W#��������������10�'0"������ ��!�����������6�W#���%��

Page 187: Analista de Sistema Operacional

� �������������������� ����������� ��� ������ ����������������������������������������������������� �� �� ����������������!��"���������#$��%� ���� ���������������������&������'(�)��������*+�� ��� ��������� ������������,�-� ����������.������/� �����������/� ������� ����������!������+� ���������$��.���������������&����� �������/� ������������ �0����1�������������������������"��(�����2�������������������������������������������� ����������3�������&������������������ � ������������ ����������45�������������3�6 ���0�������������� � �������������������47�������������������458������������������0 �����������.����0 ���������� ����������0�9���������������6 ���0������� ���� 0 ��������� ���������+���������:;<=>?@AB?C?:BD?E:C<BFG@?H;IJC?;?DKLMFLN?=OPQRH?;?ST=U=U?=VCR=H?WC?@AB?V;J?DKLMFLX?YQRSZ;R=U?WC?U;W;?UQZ<;?V=JCSZW;?C?=UI;H?QH=U?=H?V;J<=H?[\]N?[\N?[\_?a?V;J<=?[\]?b?;?R;UC?:C<BFG@?V;J?cdL?a?V;J<?[\?b?;?W=<=PJ=U=?:C<BFG@?V;J?cdL?e?=?V;J<?[\_?b?=?HCHHf;?:C<BFG@?V;J?DKL??A=H?;?:BD?S;H<QU=?QH=J?=?V;J<=?ggh?<=UIbU?�3����� ��������������������������������������� �����������:;UC?? ? ????????:iUCJ;??????????DZV;? ? cH;?jjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj?kR;UClW;lS;UVQ<=W;Jm?nn? ? c? ? @CJoZp;?WC?q;JrH<=<Z;R?

Page 188: Analista de Sistema Operacional

� �������������� �������� � �� � ����������������������������� �!����� ��� � "� � ���#�����������$������������� ������%� � �� � �������������������������������� ������&� � �� � �������������������'�������������� ������(� � �� � ��������)� **!������������� �����+�� � �� � ����������������������,������������������ �����+�� � �� � ����������$��� ���'�������������� �����++� � �� � -��������� ���������.��������������� �����+%� � �� � -�������'���/������ ��������������� �����+0� � �� � *��� 1�������!23����������������� �����%�� � �� � ��������������� 4�������������������� �����%�� � �� � 5$��� ��������� 4�������������������� �����0%� � �� � 5$��� ������ ������������������ �����00� � �� � '�������� ������������������ �����06� � �� � 53� ����� ������������������ �����0&� � �� � -����7��8�������� ������������������ �����05� � �� � ��������-59:;9�*!5������������� �����6+� � �� � ��������-59:;9�*!5������������� �����<=� � �� � !23������-'������������� �����&'� � �� � !23�����;�5������������� ������!� � �� � '��� ������ ��������������������� ������(� � �� � ��7 #�������� �������������>������������� ����� �%� � �� � �����������������������?����������� � ��� � "� � )��������?������������ �������������� ��� � �� � ���#��������?������������ ������������� �5� � "� � 5�� ��$��������?������������ � �������������*� � ��� � ���#�����������$��������� � �������������!� � "� �����������������������@��#�����;)� A������������������� �5� � "� � ;� ���� �;�7���� ������������;�A5���� ������������������� � �� � ;� ���� �;�7���� ����������������������� �����B+�C�� �� � ��������D� ���)� ���;�;���D-;5'�-�������������B+(C�� "� � D� ���)� ���;�;�)'�!�!�E!�� B%%C�� "� � D� ���)� ���(�� ��F)*<��G'�������������B+�C�� �� � ������������ �#�H�*5'��'����������I������������� �� ���������1���,����.�J��KLMNO�PQRS�T�LOUV�WOXV�YVZ�[WVL[\�]U�VLXVZVO�_�aMb[XO�[�VaVc�dU�]U[�ZVXVe�UfaYMWa[\�ONOZZgLNM[\�XV�LOUV\�\MUWaV\�WOXVU�W[ZVNVZ�V\Y[ZVU�ZVbM\YZ[X[\�U[\�O�\]hMiO�\VZj�fLMNO��PVU�O]YZ[\�W[a[kZ[\e�WOXV�W[ZVNVZ�]U�bZ]WO�U[\�LlO�mR���nZO]W�PnRS�QU�bZ]WO�LOZU[ao�O�LOUV�\MUWaV\�WOXV�ViM\YMZ�NOU�U]MYO\�VLXVZVO\�_c���pqrstqru_LYVZLVYvOZw�[NwVY�diNx[LbVyzV{]VLNVX�[NwVY�diNx[LbV�P_|yz|R�m�]U�WZOYONOaO�XV\VLkOakMXO�V\WVNMhMN[UVLYV�W[Z[�[�V\YZ]Y]Z[�}OkVaa�}VY~[ZVc�T�_|�XVhMLV�O�VLXVZV[UVLYO�X[�ZVXV�}VY~[ZV�V�O�z|�hOZLVNV�\Vb]Z[L[�V�NOLhM[�MaMX[XV�[O�_|c�PT�z|�

Page 189: Analista de Sistema Operacional

� ������������������������ ����������������������������������������������������������������������������������������������� !������!��"���������#�����$��������!�������!�����������%��!���&�'($���������������� !�����)�*���'($������� �!������!����������������������������+!���������������!�������,������ ���������������-.//012304-�����������!������������������!!5��������������!����6���������������!6������������! ����!�����������7�������������%�!��������8�����������������������������9���������!��!��!���������%��!�������9����:����&��;������!+!!����!����<��!����6����������� !�����*!���=��)�����7����> ��������������!������������?���������������������$���������������2@ABCA-$���D !������6������������������E�������������6������!����!5��������� �����������������!������!��������������5���������������������� �������!���"�����!��8���F!�������������������������� !��������!�������������� �������������8���������!���������������G��������������!�������!��H�� !������������!����������8���������������������!+!!�������!������������!������!����������!�����������������!����������!������!+!!��������������!����������������#�����������!������% ������������������������������<��!����6��G�!?���I!��?��*!���=�������!����H�������!�������+���J�)��������������!����K�L=�������!��������������6���!�������7���������!������������ !����M����6��������������������������+�������������������������������������+����������������������,���������������!������������������!��!��������������#�������������� �������������!��!�������!!5����)����>������ �������������!��������������!������N�������������������������9��������!������������-CA-#�������������������������������> ����������������������������������������!�������,����������� !������#����������������������+��6������������!��!�������������������������6������M��������������������������������+L����������������������������?���&�OPPQOPOQRSQOTUV

Page 190: Analista de Sistema Operacional

� ������������������ �������������������������������������������������������� �� ����������� ���������������������������������������������������������� �������� ������� ����������������������� !���"�������������#���������$����%� ��������$$�� �����������������������������������������&�����'��������������������������������������������� ����������������������()*+,-,./0.*123-0/0������4����������'5�������'�� ����6�����������������7����������#���� 4������������������ �����������#���������8%�����9�:;;<:;;<:;;<=.�����������$����>�?����������4�������4����������'5���� ������@����� ���$����������������7������� 4��������������������7����������������������A��>�B#�����&�� ��� ���#�9��'�������������������������4������� ���������C>�?�������� ����@� ����� �������������D&��� 4�������E����F���������������������D&���������4�����������������:==<GHG<GI<G��&��������� ���%� #����� ��������������������9�.:==<GHG<GI<:.:==<GHG<GI<H.:==<GHG<GI<J.:==<GHG<GI<;.�K����#���%� #���4������������������������9��:==<GHG<IH<G.:==<GHG<I;<I.:==<GHG<GL<J.:==<GHG<HH<II.�&����C>�&���C���������4����������'5�����������$���������:;;<:;;<:;;<=������� ����@� ���'M ����������������� �������$����������4�������������������:;;<:;;<=<=����������������������������� ����������@� ��������'M ������������@� ����7������������������� ����������������������B����������������N"&OD&������������������� ���������������������� ������C������ �����4����������'5�������B��P���Q����$�������$�� ���������9��!��"��������RST+T,-����4����UVSWTX1-,YZ0*���[,TS0\./0.UVS]-V\0����&������� �����A�����������0/0.0.�������������E������������45������B���� ������� ����������������_U[R[����������������������a��8���������������N"&OD&�����������bS/0-0YV.R[�

Page 191: Analista de Sistema Operacional

� ������������� ������������������������������ ��� ���!"�� �#��$�$������%���&��'(()*+*)*,)*�-��. ��/��#0 ��%��"12��%��%��3%�1�4���5��67�����!"�&�%�8���%��!"�����$�����#��$����8&7��%���9:���������������� ���:���:������:���$/�;1���$%<�;1���$�2��$��%������� ������������������:���=��>? @� ��6����%���&��AB����C#����8�%�#�/����%��(���'DD�<�#�����#��$���#�;�$�7��"$���E%��8���%��*���'DF��G�(�����'DD�7��"%��8���8���#0 ��%��"12��%���HIJKLMNO��/� P�!"���� ��� ��"#���/�%���%��;�#�8�����"#���/�%���%��3�����#�"#�;�$�$��%��"#�Q���%���&��AB������#8�R/����S�#���� ����$��1�����%��$�T� ��!"��%����/�%����8�� ���� ��� $�U�B����� ���#�����:����.���%��$�T� #� ���4V��"$���E�%���C#����%��W��-��X-�����"����/�&��30�8�"�#�$Y�"�8��$�8%�V�<� �#��Y��� ��%��Z����$�[8��$��X\���%��]ZB�[8��$��\��B��1���!"����/�&���4�$�#��#�"#���/�%��<�������&7���1��� �����8��1��� �#�� �����8��$��_ aN6���8�Q4�#��8������$"%��%��ZSBbAB�Y���c�#���6#��O��/���[c6O\��"�O��/�%���%��6�#��%��c�#R���<��#�8��$"�"P����T"�&7��%��1���E��;�Y��4$��##��$��C$����d0��#����"���/� P�$�/���!"��%� ��������%���&��AB�%��$�%��80����!"��/��$���A�$����$U�6��#04�#��"��W�/� P�%� ����<�#�������$�U�B�� 1�� �#����8��1��#�"���"���c6O����"�T"�&7��Y�8�� "����#�"#�1� ��%��%%��"#���#��!"�� ����8��%��"#�AB��e"�%��%���$#��fff)g�h��)����8����4�#8��<��7��8�� �#��1�������%���&��AB��G�

Page 192: Analista de Sistema Operacional

� ���������������� ����� ��� �������� ���� ���� � �� ��������� ������ � � ����� ����� ������� ������������� ������������������ ��������������������� �����!�� ����� ������"������� ���������������� ��� �� � #���������$���������"%����� � �"��&����$��������������������'��(�������� ��$���� ������)*'��(������ �+���,� �����������$� �������������� ��������������� � ��� ����'��(��$��� ����&��� �� ���� #����� �������,���� ��������� �� � #�������---./01.234����������� ����������� �� ����5 ���������$� �� �� � #����������� �������������� ��� ��� �����������6+���*�����7���5 �8���9 � �������������������� � � ������ � ��:�� �7���5 ��8����������;<=>?������ �*����(���" �����������$������������� ��%� ����� ��� ����� ��� ��� � ������������ �����%�����(����� ���� � �� ������:�� ������,���� ���������� � ����� ���� �� �%������� ��� ������@ � �������� ���� �� � ����9�������������������� � ��� �����*(��$��� ���������%����������A�B������� ���� ,��:��$�� � %���� �������� ��������� �������@�������������*�����"��������5� �������� ����������� �"� �C ��� �+������(���D��� ��E�"������ � �����#����� ������ �� ��� ��$��������� ��������������"�������� �� � � ������ ��������F�����B���������� ������������ �����*(�������� ���� ��� G���H������ ��� ��� �� G������� I������%����B����������� G ��� ,��������������*�*@���>J>K?���������������� �� ��� �,�!��� �������$���� ��%� �������� � ��� ����� ��� ��� ��������A�9%�� � ����� � ���������� ���������������� �������%����H�������G������,���$��� ��� ��7� �������8����������� ������� ��"�������*�*@��������*(��������A�� ���� �� � ������������������LLA��M�������� �� ������ ��� � �$��� �"����������"%����"�� ���������� �� ����� "��� ������ ������ ��������� ���,�9%��� �������������� ������ �����"������� ������������"�N�� ����������� � � ����������O=PQRP=?( �� �,����� �������� �����$���������� � ��� ���� ����� �� ��� �������� ����&��� ��� �� ������������ �� ������ G �������������� �� ��B �������9����������� ��� ���� ���� �����*������� ������� ���������� ���������� ��� �S�����������������������������,������� �����������,���� ����������������������������$���� �������� ���� ,�����������9���:����� �� �� �� ���E ���:����"��#�����������T �������������������� ���� �� ��� ��� ����� ����9����������������� ���:�� ����� ��:���� ������������� ��� ����� � �����#���� ����&� ��������������������������� ���������� ���B������ �����,� 9��� ����9��,��*(�,����A,� ����� ,��� � ���� ������� ������� �� ���U ������,� ����&���� ������� ��� �� ���:��� ��������� �����������������������������@� ��� �� ������ ����������� ������N ��B������ ��� � ���� �� ��@G��� � ,���� �� �� �@�����,��UD,��������� �� �������) ������ ������ �� �� �� �����V����N������S����� ����� ��?

Page 193: Analista de Sistema Operacional

� ����������� ����������������������� ����������������� �������� ��� ���������������� �� ����� ����� � �������! ����������" ���#$�������� ��� �����%� � ������ ������������� ���������&� �� ���% ������� �� ���������'��� ���� ($��� �)�����&���������� �% ������ ����*� ����� ��� �� %����&����������� ���������� � ��� �������� ���� �������&��� ������ �������+% �� ����������� �����������% �� ����������,����-������� ���.�����/��#����0 ����� �1��������� �����2������� �����!2��������������������������� ���� ����� �������������������3����4����������� ������+�����������������5��� &��������� ������ ������������(������ �+��� %�������6�7889:;;<<<=>?8>@AB8>=CDE;=FF��,G���� ����� ��������������������������������2������ ��������� ���&��� %���������1�� �� �)�������H������������ !���� �+��� %�-����������0������+ �� ���/&��������2��� �����������������5�+�������� �������� ����!���� � ���������� ��+�������� �)�������$��������� ���� � ���������0�����������,���&����&��4I#4����������������� ���J���� ! + �������K������������!�����L� �������������! � ����� ������&������ ��($�������M��N�����������2��������� ��2%�� �� �% � �����,���&������� ������������������OPQRSTUVWUVSXUYUZUTUV[YYSV�

Page 194: Analista de Sistema Operacional

� ���������� �� ����������� ����������������������������������� ��������� ������� � ���� � !��� �� �������"# � � �$�%��&�������������'��(���� ��)� ���$���*+ ��� ���,�������)� ��������� �#�#-��.� "#�� ������ �� � .�������� �� �'*����) ����� �#���������-����$�#��*/��� �� �����������0� !������ #�����#�������1)����������� �� 2��&� ���3���$ ��� ����4��� ������5���� ����������6����0��������������� �2�������������� �����������# ������������������&�����7�� ��-�'��������� #� �� ���� ��)�� �������������������� ��,������4��� ������5���� �8��

Page 195: Analista de Sistema Operacional

� ������������� ������������������������� !"#$%�%&!#'"�()'*)+%+"�,&$�-.%�/&0#'�+'�1!02'3"�$�,&$�('""&$%�*)+02$�&#!4!2+2$5�6�*)+02$�%+!')!+�2$4$"�#+%78%�9&0:!'0+�$%�;!0& �$�<0! �='�,&$�%&2+�&%�('&:'�8�+($0+"�+�"!0#+ $>5�6*')+�,&$�/?�(+""$!�&%+�0'@A'�2'�,&$�8�'�BCDEFD�$�:'%'�9&0:!'0+%�%&!#'"�2$�"$&"�()'#':'4'"G�9!:+)?�%+!"�9?:!4�2$�+()$02$)%'"�"'7)$�+"�9$))+%$0#+"�$""$0:!+!"�2$�)$2$5�H$)?�+()$"$0#+2+�+�9$))+%$0#+G�&%+�#$4+�2$�!4&"#)+@A'�$�"&+�"!0#+ $�2$�&"'5�C'%'�+"�9$))+%$0#+"�$ !"#$0#$"�"A'�%&!#'"G�-$)$%'"�+($0+"�+"�%+!"�!%(')#+0#$"�(+)+�0I"5��J�K��D$)%!#$�)$+4!L+)�:'0"&4#+"�$�+4#$)+@M$"�0+�#+7$4+�2$�%+($+%$0#'�$0#)$�$02$)$@'"�FD�$�$02$)$@'"�N6C�2'�:+:O$�6PD5�Q

Page 196: Analista de Sistema Operacional

� ������������ ���������������������������� ������ ������������������������� ���������������������� �!������������"��#�$%&!��� ���������������'()*+,-,+.�/�*01*2*3/456�.�2*(/78*2�/9�.7:*2.2;�<�� �����������'()*+,-,+.�/�*01*2*3/�=>?�.�.+2*(+*0:.2�./�+.+@*�1/�>A6;��������������������������������B�*01*2*3/�=>?�C�+/D)/(:/�)/2�E�FG:*(�H*I)2*((/(�*D�0/:.3J/���������������������������������@*I.1*+,D.7K�(*).2.1/(�)/2�@L-*0;�����������������������'()*+,-,+.�/�*01*2*3/�56�1.�)7.+.�1*�2*1*�+9M.�:.F*7.�>A6�1*8*2N�(*2����������������������������������.7:*2.1.;�6/2�1*-.97:O�.�)2,D*,2.�,0:*2-.+*�1,()/0L8*7�(*2N�9:,7,P.1.;�����'I,F*�.(�*0:2.1.(�1*�+.+@*�1/�>A6;�Q*�/��� ����:,8*2�(,1/�*()*+,-,+.1/O�D/(:2.���������(/D*0:*�.�*0:2.1.�2*-*2*0:*�.�*((*�*01*2*3/;��R�B�D*(D/�S9*�T�;����'I+79,�1/�+.+@*�1/�>A6�/�@/(:�*()*+,-,+.1/�)/2��� ���;�Q*����������-/2���������*()*+,-,+.1/O�*I+79,�/�@/(:�1/�+.+@*�1.�)7.+.�1*�2*1*�,01,+.1.�)/2���������;����>+2*(+*0:.�./�+.+@*�1/�>A6�9D.�.((/+,.3J/�*0:2*��� �����*��� ���;�Q*�444444���������:,8*2�(,1/�*()*+,-,+.1/O�.+2*(+*0:.�.�.((/+,.3J/�0/�+.+@*�1/�>A6�1.�)7.+.;�������1*�2*1*�,01,+.1.�)/2���������U��VVVWXY'()*+,-,+.�/�*01*2*3/�56�1.�)7.+.�1*�2*1*�Z�S9.7�/�+/D.01/�(*�.)7,+.;��[\]Y

Page 197: Analista de Sistema Operacional

� �������������� ������������������������������������������������������������� ����!"#$%&'()����*����+",'%'#-$���.$%/0,'1$(���2��� �����������3������4�������4���������5���������������6��������������� ������7�8�����������������������4������9�������������:����3�;�����������4����<#$#=%$0>?�@������4�����9��������5�:�������������� ��������3��������������5��������A�����B���3���C�DEF� GH!IJ�DEF���������������@3�������������K������������������ ��������������������6�� ����������������A9�:�L�M�����������������7�8�� ���������M��������������������N���� ������������A9����������������O���������������� ��������AP���������������������������Q3���3������� ������������������@3��������3�K��������4�����������L9��������3��� ������������N���� ����RS$TTU#R:�����������������������������4������VW:�XY��������������������������������� �����!������������@���������������� �����L�����������������������7�8�������L��������������������������������������������*������������Z��3�;����3����3�����������������M3��������L9���������� �����7�8���+�����������������N�����������5�����M��������������O�����V������3��[���\�] _��Y��$%/0,'1$(aab�������� �����7�8�������A��c8��N ������Q3��������d��������3��5���������������������������������������������6��K������4��������L��������������������� �������������3��7�8��@��������������9�����3�;�������������������������������K��3����e4����������L9����3�����fFg*��F�GH!IJ�DEF�'//&#1� 6���������������AP����������� ���'>.UU� c�����������������O����������� �����4�����������������L����������������������V���� ������������L��:�������h�����i�jkY�T&SS��� @����� ���������������[������������������TU#'(=�� c�����������������O����������� �����4��������������M��4�������������������������V���3�;������������� ����9�B�L��:�����������:����K������� l���Y�

Page 198: Analista de Sistema Operacional

� �������� ���������� ����������� ��� ������������������������������� ������ � ��������� ������ � �� �� ����� ����� � ���!"#��� ���������� �� ����������� ����������$%�� &���'������� �� � ���������(� ����!�)��� *�������+��� ��� �� ����� ����� � ���,-��������������.���� �� ���/� ��������������� ���� � ���,#�"00��)����������� �� ����������� �������%�)�������������1 �������+��� �������� ����� ����� � ���� �� ����� ��� �������%!"��� &���'������� ��� �����������������2����34567����� ��������+��� ���89#8�� &���'���������������� ����:;<������� �==�������=���� ��8�!>�� *?� ������ �@������������ ��� ��������� �� ��� ��� �= ��������=��� 5����������������������?� ��������� ��� ��� ������ �A������!���������������������� ������ � ��������� ������ � �� �� ����� ��� ����!,)�-9!B� *��������������� ��� ������������ ������� �������!#��������������.���� �� ���/� ��������������� ���� � ��C��!�)�B� *�������/����� ���+��� ��� �� ����� ����� � ��C�,-�� .���� �� ���/� �����/����� ���������� ��� ������� ����� � ��C%�)�� 1 ����/����� ���+��� ��� �� ����� ����� � ���� �� ����� ��� ����CD�,-�� 1�������������� �� �� ����� ����� � ��C!#��� .���� �� ���/� �����/����� ���������� ��� ������� ����� � ��C>$)�� 1 ����/����� ���+��� ��� �� ����� ��� ������ �� ����� ����� � ��">�0�� *��� ���������� ��?� �� ����������� �������>-"C>)�������&���'��������� �=���(� ���������=��E����� ������ ���+��� ��>$)�������������1 �������+��� �� �� ����� ��� ���������� ����� ����� � �3$>!"9�7��>F��� *?� �� ��������� �� �������� �� ����� ����� � ��G$,)�� ���������� ����������� ��� ���������G$")��� *��������������� ��� ������������ ������� �������-��H�� 1 �������+��� �������� ����� ����� � ���� �� ����� ��� ����-�C")�8�!>��*?� ������ �@��������� ��� ������� ��� ������� �������-�09C��� I�� ��������+��� ��-C�,-�� I�� �������������� �� �� ����� ����� � ��#�0��� 1 �������+��� �� �� ����� ��� ���������� ����� ����� � �3$>!"9�7��#)9)$#�� *?� ����= ��(J���� ����� �=����(� �� ��������������)-9���� &���'������� �� � ������3�?� �(� ����� �����(J����?������7��)�>��� K�=���� ���?� �� ���� ��������=��E��������+��� �3&�1LL� �� ���M7��

Page 199: Analista de Sistema Operacional

� �������� ���� ��������������������������������������������������� !!!!�"�#������ �$���%&�����������'��()*+,*��-����.�����/����0�"�#������'���������%��,*0�������������#1����2�34�567846�94:����������'��������������'�����!;<=>?@;A!BCD!E!CFGG!E!CHIGIFJI!BKLKMNKLOPQ!E!CHI?IR!BKLKMNKLOPQQS�!!T<UV>��������WIJ=H;UV>�CFGG! �"�#��� ����%X�����'.�������,*��������'���������������'������Y'Z��������%��,*0����������������#1�������2�34�567846�94:0�&��"�#��������#Z��������%����������������[\)*0�],-��[ -����������'��������������'�����CHIGIFJI�_�#��������%��,*��#�������������'��������������Z���������������[\)*��-���'����������&�� ������ �����0�'�#���������%���,*��#�������������������'������������������������CHI?IR� �����������%��,*��#�������������'�����������Z���������������[\)*��-���'����������&�� ������ �����0�������������%���,*��#�������������������'���������������'�������������������FaF<bFa>H!���� ��������'�����������������%&�����'�#��%&����������%��,*��#����������Z���������������[\)*��*������#���������������������c��'���������0����'�d�����������,��� �$������/�������

Page 200: Analista de Sistema Operacional

� ���������������� ���� ��� ������������� ��������� ��������� �������� �!"� �����������#�$%&'&(&)*+(�,-./01234�*+5�3063738-9:;4�*+<4�*+$4�*+=4�*+>4�*?==4�*+@4�*+'4�*A0/37B1C-4�*?D4��EFGHI))))))))JK'<>LGHI�+(� ������������������M� ���� �!"���N ����� ��M��M���M��������O�����M����������,-./0123P#�+5� ������������������M� ���� �!"���N ����� ��M��M���M����������M����O�����M����������������Q����P#�+<� ������� ��������M� ���� �!"�O��������Q� ���P�������R����� �!"������M�������#�+S� ������� ��������M� ���� �!"�O��������Q� ���P�������R����� �!"������M�������������������������������#�+$� ����� ���M� ���� �!"���� � ��TQ� ���N ����� ������M�������������#�+>� ����� ���M� ���� �!"��� ��T�� �����TU ����V��"����M�� �N�� �W7-16X1./#�+=� Y������N�������R�������M� ���� �!"����Z������ �������� ������[�T��\] !"�"���M������_M������Y�#�+==) ��T�������� ���������Qa�������M� ����V��"��������Z����� ��������M� #�+'� ����� � � �� ��������� ��������� ������M��������O� �������M� ����R� �������[�T��!"�"P#�+@� ����� � � �� ��������� ��������� ������M��������O� �����������Q� ���P#�bcdefghij) � ���k�������M���O�M� �N���� P������� ������M��l��������������� ��k��M�Q�� � ��������� #���� ��������m�������������M��������Qa�#�

Page 201: Analista de Sistema Operacional

� ����������� ���� � ��� �� �������������������������������� ��� ����� ���� �������������� �� �� ��� ������� ��������� ����� ����� ���� !"#$%��&����� ������� ����� �'��������(���)������������* ����� ��� �����%��+,-./+!01!2!3$4567�#$890:;!6<"#:=!8>��+++++?,@AB++++++CDEFG-@AB+������H�I��J�����H��I�� ������� ��%��������������)� �������K��� ���� ����������LM� N� �� � �������H���OP&������� '��Q��� ���������� �����������L.��R�����O�Q������R����������� ���������)�������������� �����LS� � ����O�Q����� � ����� ����� ������� � ������� ��������� ��Q ��T�U�VW��%��LX� O�Q��� �Q� �Y�ZO��P��[� ����\�]���� � ����� ��������Q� ����K(� ��L-�99� _;!6_$6a=!�]�O�Q������K�����R��������#$b8�������)� ������ ������������ �� �� c(Udd%��Le�#$898� N� ����������������� ���� ����� � �����#$898��Lf�#$898� N� �������������� ��� ���� ����� � �����#$898��+++LG�0g;!2$66N���� � ��� ������ ������O�Q���)� ����#$b8������� �� ��� ������ �K���Th%��LE�0g;!2$� _;!89:;b�����R��������#$b8������Q� ����Li�j�&� J����Q� �������������H�� �������� ����Lk� J������ �������������� ����� l����������������P��� ������m��nm�l���� ����� � ������������

Page 202: Analista de Sistema Operacional

� ����� ���������� ��������������������������� ��������� ������������� �!"������������#� �������$������������%�#�&������'��� �������(���������()���� ���"�*+,-�����"�.��� �"�-��� �/������-��� ���&�0�������������(����������1�2�345�� �6789:8;6��+����<����������������������#����"�.������������������� =(��� ��>?@A?>BCD�E�FCG�3�4HH�/ %&� ������%&�D�E��������������I������'����������%�*-��������%����� �G�3�4� J����%���� ��������� �BKLMNAOLPBQA>?RN>STLPBOLBU?@A?>BV2�E�� W��'���������& �X�EG24Y� J��0�� %$���������& ��Z[�3�Z� ������(����(���������0���� �2�5���� J�������������& ���X�� !"������������������������\����!]+**���0���� ��G�Z� J�����������&��������� ���������� �

Page 203: Analista de Sistema Operacional

� ������������������������ ������������ �������������������������� ���������������� !���!� �������!���������������������"�#�����$%����������&'��������� "�������(!�������������&'���)*+,-*./0� ������1��$�����2�������������#��!���� �������� ����!� �������������������������!��3��4�5��� !�������������#�����6���&�!�����!7����� ������ !���!� �����������$������������������89:;<=:98>?@A�>B?�CDE�FGHA�>?I�J���KCDE�A�>?L���F�D��A�������D��MNOPQ8 R=S<:TOPQ8?@�������������6'��������������������$����!���!������4�����?B�������������6U!����!V&!�����CDE��1 W2�����������������������?I�������������X��������5�!��������!��J���KCDE���?L�������������Y�F�D��7�� ����!���!V&!�������������1�!�!����5 ����2��������D� 6�!�����4��������������1� �������$��Z[2��/

Page 204: Analista de Sistema Operacional

� ������������ � ����������������������������������������������������������� ������ !�����"���������������#$%�$�������� &���������������#$'�()#*����� ���������*+#�,� �����-�"�� � �.�/%�0����.�������������#$������-�#$��������-��1�����������"2��������� ����� �%�$���������12��-�31���� � � ���4������������� � ���5 � ����%�67����� �������� ���5��89-�8:���;0%�

Page 205: Analista de Sistema Operacional

Page 206: Analista de Sistema Operacional

Sistemas operacionais de rede.

As modificações do hardware em favor das redes implicaram em ajustes nos Sistemas

Operacionais, adaptando-os para o novo ambiente de processamento. Os computadores

pessoais, que antes funcionavam isoladamente, já possuíam seus respectivos Sistemas

Operacionais Locais (SOL). Posteriormente surgiram os Sistemas Operacionais de Rede

(SOR), como extensão dos sistemas locais, complementando-os com o conjunto de

funções básicas e de uso geral, necessárias à operação das estações de trabalho, de

forma a tornar transparente o uso dos recursos compartilhados no sistema

computacional.

Transparência

A transparência é um dos requisitos fundamentais dos Sistemas Operacionais de Rede.

Nesse sentido, os SOR’s devem atuar de forma que os usuários utilizem os recursos da

rede como se estivessem operando localmente. A solução encontrada para estender o

Sistema Operacional das estações da rede, sem modificar sua operação local, foi a

introdução de um módulo redirecionador.

Figura 1 – Sistema Operacional Local sem Redirecionador (1) e com

Redirecionador (2)

O redirecionador funciona interceptando as chamadas feitas pelas aplicações ao Sistema

Operacional Local, desviando aquelas que dizem respeito a recursos remotos para o

Page 207: Analista de Sistema Operacional

módulo do Sistema Operacional em Rede, responsável pelos serviços de comunicação

que providenciam conexão ao dispositivo remoto.

Para as aplicações dos usuários, a instalação do Sistema Operacional de Rede é

percebida apenas pela adição de novos recursos (chamados recursos verticais) aos que

elas possuíam anteriormente. O redirecionador, como apresentado, foi o mecanismo

sobre o qual foram desenvolvidos os Sistemas Operacionais de Rede atuais.

Arquiteturas Cliente-Servidor e Peer-to-Peer

A interface entre as aplicações de usuário e o Sistema Operacional baseia-se

usualmente, em interações solicitação/resposta, onde a aplicação solicita um serviço

(abertura de um arquivo, impressão de bloco de dados, alocação de uma área de

memória etc.) através de uma chamada ao sistema operacional. O sistema operacional,

em resposta, executa o serviço solicitado e responde, informando o status da operação

(se foi executado com sucesso ou não) e transferindo os dados resultantes da execução

para a aplicação, quando for o caso. No modo de interação Cliente-Servidor, a entidade

que solicita um serviço é chamada cliente e a que presta o serviço é o servidor.

A interação cliente-servidor constitui-se no modo básico de interação dos sistemas

operacionais de redes atuais. As estações que disponibilizam a outras estações o acesso

aos seus recursos através da rede devem possuir a entidade (ou módulo) servidor. As

estações que permitem que suas aplicações utilizem recursos compartilhados com outras

estações devem possuir a entidade (ou módulo) cliente.

Nas estações que possuem o módulo cliente, o Sistema Operacional de Rede ao receber

um pedido de acesso a um recurso localizado em outra estação da rede, monta uma

mensagem contendo o pedido e a envia ao módulo servidor da estação onde será

executado o serviço. Na estação remota, o SOR recebe a mensagem, providencia a

execução (nos casos onde o pedido envolve a devolução para o SOR na estação

requerente). Quando o SOR na estação que requisitou o serviço recebe a mensagem

transportando a resposta, ele faz sua entrega à aplicação local.

Módulos Cliente e Servidor

Page 208: Analista de Sistema Operacional

As funções necessárias do SOR nos módulos clientes são diferentes das funções nos

módulos servidores. No módulo cliente, o SOR restringe-se praticamente a fornecer

serviços de comunicação de pedidos para o servidor e a entregar as respostas às

aplicações. No módulo servidor além das funções de comunicação, vários outros

serviços são executados. Um desses serviços é o controle do acesso aos recursos

compartilhados por vários usuários através da rede, para evitar, por exemplo, que um

usuário não autorizado apague arquivos que não lhe pertencem.

Portanto, podemos classificar os módulos de um Sistema Operacional de Rede,

instalados nas estações, em módulo cliente e módulo servidor do sistema operacional.

Na arquitetura Peer-to-Peer, em todas as estações o sistema operacional de rede possui

o módulo cliente (SORC) e módulo servidor (SORS), conforme mostra a Figura 2.

Figura 2 - Arquitetura Peer-to-Peer

Na arquitetura Cliente-Servidor, as estações da rede se dividem em estações clientes,

que só possuem as funções do módulo cliente acopladas ao seu sistema operacional

local, e em estações servidoras.

As estações servidoras necessariamente possuem as funções do módulo servidor e

podem, opcionalmente, possuir também as funções do módulo cliente (possibilitando,

por exemplo, que um servidor seja cliente de outro, caso típico da relação entre

servidores de impressão de arquivos). Nessa arquitetura, usualmente, as estações

servidoras não permitem usuários locais. Elas são integralmente dedicadas ao

atendimento de pedidos enviados pelas estações clientes através da rede.

Page 209: Analista de Sistema Operacional

Figura 3 - Arquitetura Cliente-Servidor com servidor não dedicado

Na arquitetura Cliente-Servidor com servidor não dedicado, as estações servidoras

possuem sistema operacional local (SOL) que é estendido por um módulo servidor

(SORS) e um módulo cliente (SORC). O módulo cliente pode ser usado tanto pelo

servidor, quanto pelas aplicações dos usuários locais da estação servidora. Assim, os

recursos locais das estações servidoras são compartilhados tanto pelos usuários

atendidos pelo sistema operacional local (que também podem ter acesso a serviços de

outros servidores) quanto pelos usuários remotos que fazem pedidos ao Sistema

Operacional de Rede através da rede.

É importante observar que, como uma estação servidora possui um módulo cliente, seu

módulo servidor pode ser cliente de outra estação servidora, como em alguns servidores

dedicados.

Page 210: Analista de Sistema Operacional

Segundo estudo realizado pelo Gartner Group, Inc., apresentado por Donna Scott em sua palestra Operation Zero Downtime, em maio de 2002, 80% das causas de downtime nos serviços de TI são decorrentes de problemas relacionados com a operação destas atividades, tais como:

• Aplicações não-testadas.

• Má gerência de mudanças.

• Sobrecarga de processamento.

• Falhas em procedimentos.

• Falhas no cumprimento de requisitos.

• Erros relacionados à segurança ou às rotinas de backup.

O quadro descrito pelo estudo do Gartner Group, Inc. foi também evidenciado pela pesquisa realizada pela Financial Insights, em junho de 2003, a qual indicou que 88% dos executivos de serviços financeiros afirmam que a eficiência operacional dos serviços de TI é muito mais preocupante do que o atendimento das novas necessidades de TI de suas organizações.

Exemplos de prejuízos causados pelas falhas em serviços de TI foram os casos ocorridos com as seguintes organizações, segundo mostra a Tabela 1.1:

Tabela 1.1 – Organizações prejudicadas por falhas em serviços de TI

Empresa Data Ocorrência

AT&T Abril de1998A atualização da versão do sistema prevista para ser realizada em 6 horas, levou 26 horas. Custo de US$ 40 milhões em descontos nas faturas de serviço devido ao não-cumpri-mento de acordos de nível de serviço celebrados com os seus clientes finais.

eBay Junho de 1999Indisponibilidade durante 22 horas devido à falha no sistema. Custo estimado entre US$ 3 e 5 milhões em receitas e declínio de 26% no valor das ações.

Hershey’s Setembro de1999

Falhas no sistema devido à estratégia de implementação de nova versão. Custo não-estimado com o atraso no envio de encomendas, 12% de redução nas ven-das do trimestre e diminuição de 19% no lucro líquido do trimestre em relação ao mesmo período do ano anterior.

Implementação do gerenciamento de serviços de TI

Page 211: Analista de Sistema Operacional

Para se ter uma idéia do valor financeiro decorrente dos problemas nos serviços de TI, basta verificar o quanto uma organização dependente dos serviços de Tecnologia da Infor-mação para a consecução dos seus negócios pode vir a perder em termos de receita por hora de interrupção em um dos seus serviços de TI, conforme exemplificado na Tabela 1.2.

Tabela 1.2 – Valor por hora de interrupção dos serviços de TI

Indústria Serviço Custo médio por hora de interrupção do serviço (US$)

Financeira Operações de corretagem 7.840.000

Financeira Vendas por cartão de crédito 3.160.000

Mídia Venda por pay-per-view 183.000

Varejo Vendas pela TV 137.000

Varejo Vendas por catálogo 109.000

Transportes Reservas aéreas 108.000

Entretenimento Venda de ingressos por telefone 83.000

Entregas rápidas Entrega de encomendas 34.000

Financeira Pagamento de taxas via ATM (Automatic Teller Machine) 18.000

O Gerenciamento de Serviços de Tecnologia da Informação é o instrumento pelo qual a área pode iniciar a adoção de uma postura proativa em relação ao atendimento das necessidades da organização, contribuindo para evidenciar a sua participação na geração de valor. O Gerenciamento de Serviços de TI visa alocar adequadamente os recursos disponíveis e gerenciá-los de forma integrada, fazendo com que a qualidade do conjunto seja percebida pelos seus clientes e usuários, evitando-se a ocorrência de problemas na entrega e na operação dos serviços de Tecnologia da Informação. Para alcançar este ob-jetivo, a tática que vem sendo adotada é o desenho, a implementação e o gerenciamento de processos internos da área de TI de acordo com as práticas reunidas na Information Technology Infrastructure Library (ITIL)1, conforme demonstrado na Figura 1.1.

ISO/IEC20.000-1

ISO/IEC20.000-2

Information TechnologyInfrastructureLibrary (ITIL)

Processos internos da área de TI

Gerenciamento de Serviços de TI

Procedimentos

Como fazer

Execução

Figura 1.1 – Estratégia de implementação do Gerenciamento de Serviços de TI.1 ITIL é marca registrada do Office of Government Commerce.

Page 212: Analista de Sistema Operacional

30 Gerenciamento de Serviços de TI na Prática

A ITIL é a abordagem padronizada mais utilizada para o Gerenciamento de Serviços de TI no mundo, conforme comprovou uma pesquisa realizada pela International Network Services com 194 organizações de todo o mundo. O resultado, apresentado na Figura 1.2, constatou que 39% das organizações responderam que utilizam a ITIL, quer de modo isolado ou em conjunto com outras práticas desenvolvidas internamente ou de mercado. A vantagem da ITIL aumenta, quando se considera que ela é base para as abordagens denominadas Information Technology Service Management (ITSM) e Microsoft Operations Framework (MOF).

e

Figura 1.2 – Resultado da pesquisa sobre adoção de práticas de Gerenciamento de Serviços de TI2.

A ITIL provê um abrangente e consistente conjunto de melhores práticas para a iden-tificação de processos da área de TI e o alinhamento dos seus serviços às necessidades da organização, promovendo uma abordagem qualitativa para o uso econômico, efetivo, eficaz e eficiente da infra-estrutura de TI, objetivando obter vantagens para a organização tanto em termos de redução de custos pelo aumento da eficiência na entrega e suporte dos serviços de TI quanto de incremento da capacidade da organização de gerar receita, permitindo que a área concentre seu esforço em novos projetos para o atendimento à es-tratégia de negócio da organização. Estes dois aspectos, alinhamento e serviço, conforme demonstrado na Figura 1.3, possibilitam a alavancagem da contribuição da área de TI na geração de valor para a organização.

Valor de TI

Alinhamento

Serviço

Valor

Custo

Incrementoda Geraçãode Receita

Aumentoda Eficiência

Tempo

Figura 1.3 – Valor de TI.

A ITIL habilita o aprovisionamento da organização com serviços de TI de alta qualidade, valorizando o relacionamento com os clientes, o que, por sua vez, permite assegurar cada vez mais o atendimento de suas expectativas, sem esquecer das necessidades e das expectativas

2 ITServiceManagementandITILSurvey–InternationalNetworkServices.

Page 213: Analista de Sistema Operacional

31Capítulo 1 • Introdução

dos usuários. Isto significa que a área de TI deve prestar seus serviços para a organização de acordo com as necessidades dos seus clientes, ou seja, demais áreas de negócio, fortalecendo o relacionamento da área de TI com os mesmos, bem como dela para com seus parceiros, fornecedores de Tecnologia da Informação e serviços correlatos, pois a área de TI depende deles para a consecução de seus objetivos de nível de serviço na entrega e na operação dos serviços de TI para a organização, conforme ilustra o diagrama da Figura 1.4.

Áreas de Negócio

Área de TI

Serviços de TI

Serviços Internos

Atividades

Recursos(Commodities & Utilities)

Outta

sking

Outso

urcin

g

Serviço 1 Serviço 2 Serviço n

Figura 1.4 – Dependência da área de TI de seus parceiros.

Um aspecto relevante para a área de TI é a sua estratégia de contratação de mão-de-obra, em especial a opção por um modelo multisourcing, ou seja, a combinação adequada de recursos internos e externos. O ponto de equilíbrio ideal será obtido pela realização de uma análise complexa e criteriosa das operações do setor de TI, bem como do estudo dos direcionadores estratégicos definidos pela organização para a área de TI. A avaliação cuidadosa do que pode e deve ser passado para a mão de terceiros é essencial para o su-cesso de qualquer iniciativa de outsourcing ou outtasking.

O outtasking consiste na ação de terceirizar tarefas específicas de uma organização, e não mais uma função de negócio como no caso do outsourcing. O outtasking, por sua vez, é um conceito mais aceitável de terceirização de tarefas, uma vez que o outsourcing significa perda de controle e de comando, pois a responsabilidade do gerenciamento passa a ser do fornecedor contratado.

Hoje, as organizações já estão mais maduras em relação ao assunto e tomam decisões mais estratégicas que levam em conta não apenas custo, mas a criticidade de cada processo da área de TI para a geração de valor para a organização. A organização precisa observar seus objetivos estratégicos. Se for possível padronizar determinada atividade ou serviço interno da área de TI, provavelmente há uma oportunidade de terceirização.

Page 214: Analista de Sistema Operacional

32 Gerenciamento de Serviços de TI na Prática

Na sua maioria, em torno de 90%, os contratos de fornecimento externo na área de TI são focados na redução de custos, mas esta não deve ser a única razão para se partir para o outsourcing ou para o outtasking. Já se inicia um movimento das organizações em direção a um estágio mais avançado que visa à melhoria da eficiência operacional, pois com o tempo a questão do custo se esvazia e, se não forem promovidos avanços, fornecedor e cliente ficam insatisfeitos com os resultados do acordo. Neste aspecto, deve-se eliminar um dos maiores mitos da terceirização, que é a idéia de que sempre acarreta redução de custos.

A ITIL, criada a partir da necessidade de padronizar os processos da área de TI visando à terceirização, baseia-se na experiência coletiva de inúmeros praticantes do Gerenciamento de Serviços de TI de organizações privadas e públicas de todo o mundo. Esta é a razão pela qual vem se tornando um padrão “de fato” na área de Gerenciamento de Serviços de TI, adotada por organizações-líderes em seus segmentos de atuação em escala mundial, como, por exemplo, Microsoft, IBM, British Petroleum, Barclays Bank, HSBC, Boeing, Caterpillar, Hershey’s, Guinness e Procter & Gamble, bem como por grandes organizações públicas, como a US Army e a US Navy.

No Brasil esta tendência também já é sentida, haja vista o envolvimento de organizações como Caixa de Assistência dos Funcionários do Banco do Brasil (Cassi), Companhia do Metro-politano de São Paulo (Metrô), Serviço Federal de Processamento de Dados (Serpro), Sonopress, Banco Real, TIM, Carrefour, Odebrech, Roche, Alcoa, Santander Banespa, Philips, Orbitall e outras, conforme notícias e casos de sucesso publicados na imprensa especializada.

1.1 Panorama atual

Organizações consideradas líderes em suas indústrias estão deixando de ser organizações puramente focadas em custo para se tornarem organizações focadas em valor. Isto pode ser constatado pela atual prática da troca dos indicadores de desempenho (KPIs) puramente operacionais por indicadores de desempenho derivados da estratégia da organização e que permitem a monitoração do desempenho da organização na execução de sua estratégia, a partir de diversas perspectivas, além da financeira, tradicionalmente utilizada.

Nessas organizações, os Chiefs Information Officer (CIOs) têm trabalhado no sentido de atender aos seus clientes (áreas de negócio) com produtos e serviços de TI a um baixo custo, lançando mão do trabalho executado pela combinação de equipes internas e externas, sob a forma de outsourcing e/ou outtasking. Entretanto, os CIOs modernos reconhecem algumas falhas associadas com esta abordagem, o que força a discussão sobre o fato do valor de TI ser ou não baseado estritamente em custo.

Além disso, os CIOs estão passando a desempenhar um papel em que eles deixam de focar o custo simplesmente para focar a forma como a área de TI contribui para a efetiva maximização do valor para o negócio, passando a ter a necessidade de evidenciarem como área de TI habilita a capacidade de geração de valor da organização, mas sem se esquecer do gerenciamento do custo de TI.

Page 215: Analista de Sistema Operacional

33Capítulo 1 • Introdução

O panorama atual força os CIOs a desejarem ao mesmo tempo ganhos de produtivi-dade e eficiência, em um extremo, e aumento da capacidade da área de TI em atender as novas demandas da estratégia de negócio e assegurar a sua contribuição para a geração de valor para a organização no outro.

O modo de atender às duas pontas do desafio colocado é aumentar a produtividade interna da equipe da área de TI, visando diminuir o gasto com os serviços de TI que não contribuem para a geração de valor para a organização, investindo o esforço economizado na disponibilização de serviços de TI que realmente contribuam para a geração de valor para a organização.

A Figura 1.5 apresenta a distribuição das horas disponíveis da equipe da área de TI entre processos que visam ao atendimento de necessidades de TI da organização e gastos gerais destinados às atividades internas da área de TI e, portanto, não agregam diretamente valor para a organização. No melhor caso, essa relação é de 10% aplicados em gastos gerais e 90% em processos destinados ao suporte dos serviços de TI necessários à organização.

75-90%

10-25%

Processos

Gastos gerais

Estratégicos

Táticos

Operacionais

Treinamento

Projetos internos

Reuniões etc.

Figura 1.5 – Distribuição das horas disponíveis da equipe TI. Fonte: Gartner Group, Inc.

1.2 Necessidade do alinhamento de TI à estratégia de negócio da organização

O CIO encontra-se diante do desafio de coordenar e trabalhar em parceria com as demais áreas de negócio da organização, garantindo o almejado alinhamento estratégico, visando à geração de valor para a organização, permitindo o aproveitamento de novas oportunida-des de negócios, em paralelo com a necessidade de reduzir o Custo Total de Propriedade (Total Cost Ownership – TCO) de TI, de modo a maximizar a capacidade de geração de valor das oportunidades de negócios já aproveitadas.

O TCO, metodologia desenvolvida pelo Gartner Group, Inc., é definido como todo custo associado com a aquisição, manutenção e uso de um ativo de TI durante toda a vida útil prevista para ele. O processo de cálculo do TCO é descrito na Figura 1.6.

Page 216: Analista de Sistema Operacional

34 Gerenciamento de Serviços de TI na Prática

PlanejamentoGerenciamento

Implementação

Validação Melhoria

Análise

Figura 1.6 – Processo de cálculo do TCO.

O desafio apresentado, aparentemente contraditório, remete o trabalho da área de TI à execução da estratégia de negócio da organização, ou seja, a área de TI deve garantir que tudo que é feito em termos de TI é em função da estratégia de negócio e terá seu retorno em geração de valor identificável nos resultados da organização.

Para que este desafio seja vencido, a área de TI deve entender que, como em qualquer indús-tria, os clientes querem muito mais do que a entrega de produtos; eles querem serviços, ou seja, a entrega de serviços, e não de produtos. Neste novo cenário, a área de TI necessita determinar que serviços ela entrega para a organização, qual o valor desses serviços para a execução da estratégia de negócio da organização e como garantir que tais serviços sejam entregues dentro dos parâmetros de qualidade (níveis de serviço) exigidos por seus clientes e usuários, zelando sempre por assegurar a melhor relação custo/benefício para a organização.

O primeiro passo rumo à vitória desejada é motivar e envolver os integrantes da área de TI em um processo de transformação das suas convicções, do seu conhecimento e de suas expectativas, de modo a propiciar uma mudança no seu comportamento, o qual deverá passar a ser guiado pela observância dos fatores identificados na coluna “Cenário atual” da Tabela 1.3.

Tabela 1.3 – Cenário anterior versus cenário atual

Cenário anterior Cenário atualAtendimento do usuário Atendimento do clientePerspectiva interna Perspectiva externaEsforço pessoal Esforço repetitivo e medidoFoco na tecnologia Foco no processoProcessos ad-hoc Processos racionalizadosRecursos internos Recursos internos e externosComportamento reativo Comportamento proativoVisão fragmentada Visão integradaSistema manual Sistema automatizadoGestor de operações Gestor de serviços

Page 217: Analista de Sistema Operacional

35Capítulo 1 • Introdução

1.3 Papel da área de TI

O papel desempenhado pela área de TI em uma organização-líder em seu segmento de atuação move-se da eficiência e eficácia para a efetividade e a economicidade em relação à estratégia de negócio da organização, forçando a implementação de um Gerenciamento de Serviços de TI que leve à exteriorização da contribuição da área de TI para a geração de valor para a organização, maximizando o retorno para o negócio dos investimentos (CAPEX) e das despesas (OPEX) efetuados em Tecnologia da Informação.

Neste novo cenário, jargões como “melhores práticas”, “otimização de processos”, “qua-lidade do serviço” e “alinhamento estratégico dos serviços de TI ao negócio” deixam de ser meros jogos de palavras e passam a ser parte do novo estilo de vida de todas as áreas TI. Sendo assim, tais áreas tendem a adotar processos guiados pelas melhores práticas do mercado com o objetivo de não terem de aprender e crescer por meio de tentativas, erros e atribulações já vivenciadas e superadas por outras organizações.

A ITIL é um conjunto de melhores práticas que vem ao encontro do novo estilo de vida imposto às áreas de Tecnologia da Informação, habilitando o incremento da maturidade do processo de gerenciamento de TI, propiciando a construção de um caminho entre o nível denominado “Caótico” e o nível “Valor”, em que é possível a demonstração do valor de TI para a organização, conforme ilustra a Figura 1.7.

Valor

Serviço

Pró-ativo

Reativo

Caótico

Gerenciamento Financeiro e alinhamento entre TI e o Negócio,demonstrado por meio de indicadores de desempenho

Gerenciamento do nível de serviço e da capacidade

Gerenciamento da performance, configuração e disponibilidadeGerenciamento das mudanças e dos problemas

Gerenciamento dos incidentes e eventosGerenciamento do inventário

Existência de vários Help-Desks, inexistência de supervisãocentralizada e notificação de problemas por meio de chamadasde usuários

Gerenciamento dos ServiçosMaturidade do Processo deGerenciamento de TI

Figura 1.7 – Maturidade do processo de gerenciamento de TI em relação à ITIL. Fonte: Adaptado pelos autores a partir do modelo desenvolvido pelo Gartner Group, Inc.

Page 218: Analista de Sistema Operacional

36 Gerenciamento de Serviços de TI na Prática

1.4 Importância da área de TI

A cada dia que passa, as organizações tornam-se mais dependentes da Tecnologia da Informação a fim de satisfazer seus objetivos estratégicos e para atender às necessidades do negócio em que atuam. Uma área de TI que não considerar os objetivos estratégicos da organização em que se insere como os seus próprios objetivos, será uma área de TI que deseja apenas ser um simples provedor de tecnologia, haja vista que até mesmo os provedores de tecnologia, atualmente, tendem a preocupar-se com a estratégia de negócio de seus clientes, condição básica para a venda de serviços sob demanda.

Pela observação da Tabela 1.4, a qual reproduz resultado de uma pesquisa feita pelo IT Governance Institute, conclui-se que mais de 50% das organizações, na média dos dife-rentes segmentos de indústria, consideram a área de TI muito importante para execução da estratégia de negócio.

Tabela 1.4 – Importância da TI em diferentes indústrias. Fonte: IT Governance Global Status Report, IT Governance Institute, 2004.

Setor Muito importante Importante Indiferente Pouco importanteSetor público 56% 40% 4% 0%

Varejo 38% 43% 19% 0%

Manufatura 45% 45% 9% 1%

Financeira 59% 38% 3% 0%

TI/Telecomunicações 65% 28% 7% 0%

O fato da importância da área de TI para a execução da estratégia de negócio crescer, faz com que ela seja vista como uma parte da organização, tendo sua estratégia estritamente interligada com a de negócio, de modo que tudo que for feito em termos de TI possa ser demonstrado na forma de obtenção de valor para a organização. A área de TI deveria se comportar como um sócio da sua organização, criando uma relação de negócio com as demais áreas de negócio da organização.

Para a maioria das organizações, já é passado remoto o tempo em que a área de TI poderia limitar-se apenas à entrega de produtos de tecnologia, atuando como um provedor de tecnologia, com sua atenção exclusivamente dedicada ao Gerenciamento da Infra-Es-trutura de TI. Com o passar do tempo, a área de TI está sendo incentivada a elevar sua maturidade em termos de atuação dentro da organização, e a tendência é de se tornar um parceiro estratégico dos demais setores de negócio que compõem a organização, dotando-se de uma forte Governança de TI, alinhada com a governança corporativa. Na Figura 1.8, apresenta-se esta evolução, sendo que, a partir do nível 2, quando a área de TI entende que deva ser reconhecida como um provedor de serviços, o Gerenciamento de Serviços de TI torna-se um aspecto indispensável para o alcance da respectiva maturidade e da sua sustentação visando à criação da base de confiança perante a organização para que ela possa ascender ao terceiro nível de maturidade da função de TI.

Page 219: Analista de Sistema Operacional

37Capítulo 1 • Introdução

Parceiro Estratégico 3

Provedor de Serviço 2

Provedor de Tecnologia 1

Maturidade da Função de TI

Governança de TI

Gerenciamento de Serviço

Gerenciamento da Infra-Estrutura

Tempo

Figura 1.8 – Escala de maturidade da função de TI3.

1.5 TI tradicional versus TI orientada a serviços

Atualmente, o termo serviço é aplicado virtualmente em todo contexto da área de TI, sem que haja um claro entendimento do significado que tem hoje. Plataformas tecnológicas e produtos físicos não são serviços, mas, sim, pontos de acesso ou habilitadores dos serviços. Em termos organizacionais, uma área de TI orientada a serviços é muito diferente de uma outra que adota o modelo baseado na disponibilização de recursos, também conhecido como “tradicional”.

Muitas áreas de TI estão iniciando um movimento para se tornarem orientadas a servi-ços sem uma clara visão do escopo, dos riscos e do retorno desta nova abordagem. Como resultado, a taxa de falhas é expressiva e, a cada dia que passa, mais visível.

A diferença entre uma área de TI que adota o modelo tradicional e outra orientada a serviços pode ser resumida da seguinte forma: a TI tradicional define a si mesma como uma provedora de tecnologia, trabalhando de dentro para fora; a TI orientada a serviços se autodefine como uma provedora de serviços, trabalhando de fora para dentro. Tais pers-pectivas de atuação também representam diferentes atributos das culturas centralizada na tecnologia e no cliente, respectivamente.

Organizações que adotam a cultura centralizada na tecnologia operam a área de TI como um centro de custos focado na maximização do uso dos seus ativos. As áreas de TI de tais organizações tendem a ser organizadas em silos (alinhadas ao redor de funções, conhecimentos, capacidades e plataformas tecnológicas), focadas em custos, monopolistas e não-competitivas. Estas áreas de TI aceitam as restrições de sua capacidade de forneci-mento como elas são.

3 Metodologia de avaliação para a implementação da Governança de TI desenvolvida pelos autores.

Page 220: Analista de Sistema Operacional

38 Gerenciamento de Serviços de TI na Prática

As áreas de TI de organizações que adotam a cultura centralizada no cliente utilizam um modelo de entrega misto, baseado no melhor equilíbrio entre fornecedores externos, nos formatos de outsourcing e outtasking, e equipes internas. Elas tendem a ser competitivas, possuem diversos fornecedores, são orientadas a processos e negociam com os clientes para garantir que a demanda é fundamentada e que os recursos necessários para garantir o atendimento estarão disponíveis.

A nova abordagem necessita de diferentes comportamentos, não apenas dos integrantes da área de TI, mas também das áreas de negócio, exigindo o aprendizado por ambas as partes de novos estilos de interação. Cabe à área de Tecnologia da Informação, como um primeiro passo, definir o seu Catálogo de Serviços de TI como algo distinto dos processos e outros elementos necessários para a entrega e o suporte dos serviços de TI, mas de forma alinhada com as necessidades da organização, conforme ilustra a Figura 1.9.

Alin

ham

ento

da á

rea d

e TI à

Est

raté

gia d

e Neg

ócio

Processo de Negócio

Serviços de Negócio

Serviços de TI

Serviços Internos

Atividades

Recursos

Estratégia de Negócio

Catálogo de Serviços de TI

Figura 1.9 – Posicionamento do Catálogo de Serviços de TI (conforme a metodologia IT Flex®).

1.6 Como realizar a mudança

A realização de uma mudança de comportamento, associada à transformação das convic-ções, conhecimento e expectativas dos integrantes da área de TI, não é uma tarefa simples e muito menos rápida. Para tornar ainda maior este desafio, a modificação almejada será feita com pessoas que já se sentem esmagadas pela crescente aceleração da mudança em suas vidas profissional e pessoal. Assim, são necessárias diversas interações até a obtenção do nível adequado de comportamento dos integrantes da equipe área de TI e dos respectivos resultados para a organização. Entretanto, a mudança descrita é uma tarefa essencial para a consecução do objetivo de transformar a atuação da área de TI, propiciando a elevação da sua maturidade.

Um processo de mudança envolve diversos momentos distintos, entre a situação atual e a situação desejada, conforme demonstra a Figura 1.10. O início de uma mudança via

Page 221: Analista de Sistema Operacional

39Capítulo 1 • Introdução

de regra provoca uma queda do desempenho atual, mas este é o preço a pagar para se conseguir um desempenho superior no futuro.

Situação Atual

Situação Desejada

Negação

Frustração

Inevitável

Aceitação

Entusiasmo

Figura 1.10 – Efeitos do processo de mudança.

Para que se obtenha sucesso na execução de uma mudança é necessário que todos os envolvidos:

• Reconheçam a necessidade da mudança.

• Conheçam a “visão da mudança”.

• Reconheçam as condições limitantes.

• Selecionem o método a ser utilizado na mudança.

• Implementem e avaliem o do método utilizado para introduzir a mudança.

De maneira simplificada, a realização de uma mudança pode ser dividida em quatro fases, que, dependendo dos resultados obtidos, poderão se repetir de forma seqüencial até que seja assegurada a implementação da mudança desejada. Estas quatro fases são descritas a seguir:

• Descongelar – Preparação para a mudança. Convencer as pessoas a saírem do conforto da situação atual e moverem-se pela nova e turbulenta maneira de se fa-zerem as coisas (a transição) e chegarem àquilo que pode ser uma situação futura distante e pouco clara neste primeiro momento. Ou seja, convencer as pessoas a abandonarem a rotina, os padrões, as convicções e as expectativas estabelecidas.

• Reconfigurar – Realização da mudança. É a fase do processo de mudança em que as pessoas se livram da rotina, dos padrões, das convicções e das expectativas estabelecidas. Elas não mais se comportam como no passado. Entretanto, ainda não assumiram de modo definitivo o novo comportamento desejado. Inicia-se a mudança na forma de trabalhar.

• Recongelar – Fixação da mudança. As pessoas nesta fase já passaram a trabalhar segundo o novo comportamento desejado, e é chegada a hora de interromper as ações de motivação para a mudança. Cessa-se a pressão e encerram-se as alterações,

Page 222: Analista de Sistema Operacional

40 Gerenciamento de Serviços de TI na Prática

promovendo-se a volta de uma rotina de trabalho, da estabilidade, muito diferente, porém, da que existia antes do início do processo de mudança.

• Analisar – Obtém-se sucesso na realização da mudança? Nesta fase, procura-se medir os resultados após a implementação da mudança, validando-se o alcance das metas e dos objetivos traçados para a mudança implementada, além da quantifi-cação dos ganhos em relação aos resultados do comportamento existente antes de iniciado o processo de mudança. Em caso negativo, novo plano de mudança deverá ser feito e retoma-se o processo de mudança em sua primeira fase.

A mudança não pode ser vista como um evento momentâneo ou uma fase passageira, mas encarada como um processo manuseável e gerenciável. Portanto, antes de ser realizada é necessário o conhecimento dos Fatores Críticos de Sucesso (FCSs).

Gerir um processo de mudança é, atualmente, uma necessidade. O sucesso e a sobrevi-vência de uma organização dependerão de quão bem as decisões de mudança podem ser implementadas. Como resultado, sempre haverá perdedores, sobreviventes e vencedores.

A seguir, apresentam-se alguns indícios4 sobre os resultados para a área de TI dos pro-cessos de mudanças relacionados com o Gerenciamento dos Serviços de TI:

• Propósito da adoção do gerenciamento de serviços

• Perdedoras – Querem reduzir as reclamações dos usuários e clientes, usando-o como ferramenta de marketing.

• Sobreviventes – Querem permanecer competitivas.

• Vencedoras – Querem ser vistas por todos os stakeholders da organização como uma área que cria valor.

• Escolha da ferramenta/metodologia

• Perdedoras – Sempre procuram a última moda.

• Sobreviventes – Escolhem a abordagem de um guru e se atêm a ela.

• Vencedoras – Examinam todas as opções e seus impactos sobre a organização, muitas vezes compondo uma sob medida para as suas necessidades.

• Planejamento para o gerenciamento dos serviços de TI

• Perdedoras – Planejam para implementar a ferramenta/metodologia da moda.

• Sobreviventes – Usam uma abordagem-padrão, comprovada, já utilizada com sucesso por outras organizações.

• Vencedoras – Utilizam um plano altamente personalizado.

4 Adaptado pelos autores da pesquisa realizada por H. James Harrington e James S. Harrington.

Page 223: Analista de Sistema Operacional

41Capítulo 1 • Introdução

• Retorno obtido do Gerenciamento dos Serviços de TI

• Perdedoras – Não medem o retorno sobre os investimentos realizados. As medi-ções concentram-se na verificação da execução de atividades, não nos resultados obtidos.

• Sobreviventes – Aguardam o retorno dos investimentos a longo prazo. A ênfase ainda é sobre a verificação da execução das atividades.

• Vencedoras – O Gerenciamento dos Serviços de TI deve ser pago por si mesmo à medida que avança. Sistemas de medição são estabelecidos no início do pro-cesso de mudança para medir o retorno advindo dos investimentos realizados de modo contínuo.

1.7 Processo

As organizações, desde o início, foram construídas sob rígidas estruturas hierárquicas, utilizadas principalmente como um instrumento de controle do trabalho dos indivíduos e, conseqüentemente, como meio de assegurar o cumprimento dos compromissos firmados com os clientes em relação à entrega de serviços e produtos. Com o crescimento das organizações, essas mesmas estruturas hierárquicas, responsáveis pelo sucesso, tornaram-se um obstáculo para a continuidade do atendimento das expectativas dos seus clientes, transformando a organização em um arquipélago de departamentos, todos preocupados com a execução e o bom desempenho de sua função, perdendo-se de vista o objetivo final da organização, ou seja, o resultado do trabalho conjunto dos diferentes departamentos. A área de TI não é uma exceção a esta regra, tendo sido também estruturada sob uma divisão funcional.

Quando se fala em processo, passa-se a perceber a interação entre os diversos depar-tamentos que compõem uma organização, conforme ilustrado na Figura 1.11, já que um processo é uma série de ações, atividades, mudanças etc., conectadas entre si e realizadas por agentes com o fim de satisfazer um propósito ou alcançar uma meta.

Os processos são o mais alto nível de definição de atividades de uma organização. Os procedimentos (instruções de trabalho) são mais detalhados e descrevem exatamente o que deve ser executado em determinada atividade do processo. Os procedimentos podem variar de um departamento para outro, assim como de uma atividade para outra. Por exemplo: em um processo de tratamento de incidentes, é exigido que, ao se registrar um incidente junto ao Service Desk, sejam fornecidos determinados dados de um usuário das áreas de negócio A e outros de um usuário da área de negócio B (diferença de depar-tamento para departamento). Durante o tratamento do incidente, ao se modificar o nível de atuação, novas informações poderão ser acrescidas ao registro do incidente, de modo a melhor caracterizá-lo para tratamento pelo novo nível de atendimento (diferença de atividade para atividade).

Page 224: Analista de Sistema Operacional

42 Gerenciamento de Serviços de TI na Prática

Resu

ltado

Objet

ivoProcesso

Departamento A

Procedimento

Atividade 1

Departamento C

Procedimento

Atividade 3

Departamento B

Procedimento

Atividade 2

Figura 1.11 – Processo.

Uma área de TI, ao procurar se estruturar por processos, em geral descobre que é impossível sobrepor um processo integrado a uma estrutura hierárquica fragmentada tradicional, baseada na divisão funcional. Algumas áreas de TI chegam a dar alguns passos nessa direção, mas desistem logo depois, sem saber ao certo como prosseguir.

Para avançar nesse propósito de forma consciente, é necessário conhecer tanto os problemas das estruturas tradicionais quanto os conceitos fundamentais da organização baseada em processos.

As estruturas convencionais têm algumas características anacrônicas que podem com-prometer seu desempenho em contextos competitivos, como o atual cenário da economia mundial. Elas priorizam as funções (áreas verticais) em detrimento dos processos essen-ciais para a criação de valor e exageram na divisão de tarefas, ao adotarem a otimização do funcionamento das áreas funcionais, levando à hiperespecialização.

As estruturas hierárquicas tradicionais são rígidas, pesadas e repletas de caixinhas que executam pedaços fragmentados de processos de trabalho. Em cada caixinha predominam atividades padronizadas e controladas por vários níveis hierárquicos, cuja função princi-pal é garantir o cumprimento das normas, muitas vezes esquecendo-se do objetivo final desejado pela organização. Ademais, apresentam muitos níveis hierárquicos, o que leva à lentidão na tomada de decisão, ao desperdício de recursos e à rigidez.

Uma área de TI orientada por processos pressupõe que seus integrantes trabalhem de forma diferente. Em lugar do trabalho individual e voltado para as tarefas, é valorizado o trabalho em equipe, a cooperação, a responsabilidade individual e a vontade de fazer melhor. Ela projeta e mede cuidadosamente seus processos, faz com que todos os envol-vidos entendam e se responsabilizem por eles, possibilitando, assim, que se desenvolva o sentimento de “propriedade do processo”.

Ao contrário da priorização das áreas de TI verticais, a visão horizontal da área constitui uma forma de identificar e aperfeiçoar as interfaces funcionais, que são os pontos nos quais o trabalho que está sendo realizado é transferido de uma subárea para a seguinte.

Nessas transferências podem ocorrer erros e desperdício de tempo. Assim, a área de TI terá melhor aproveitamento da experiência e do conhecimento, adquiridos em todas as suas subáreas, se compartilhá-los em um fluxo horizontal otimizado.

Page 225: Analista de Sistema Operacional

43Capítulo 1 • Introdução

Para a obtenção do sucesso em uma abordagem por processos, é necessário que todo processo tenha um proprietário, responsável pela sua definição, gerenciamento e demons-tração dos resultados perante a organização.

Um processo é formado por diversas atividades que interagem para o alcance do objetivo especificado e a geração do resultado desejado. Cada atividade, conforme demonstra a Figura 1.12, é composta por uma sucessão de tarefas, cada qual incumbida de transformar uma informação colocada em sua entrada, pela execução do seu algoritmo sob a obser-vância de regras e de seu responsável, em uma informação de saída apropriada para servir de entrada para a próxima tarefa.

Tarefa 1

Responsável

Regras

SaídaTarefa 2

Responsável

Regras

Saída deInformação

Entrada

Entrada deInformação

Atividade

Figura 1.12 – Composição de uma atividade.

Os processos podem ser ainda mais detalhados:

• Cada processo tem entradas e saídas, definindo o que necessita ser feito para atingir o(s) objetivo(s) e que outros processos necessitam dele para atingir seus objetivos.

• Para cada processo deve existir um responsável, como, por exemplo, o gerente de Capacidade, que responde pela definição do processo, assim como pelo sucesso das atividades do processo.

• Cada processo pode ser dividido em uma série de tarefas. Cada uma será executada por um ator (participante do processo) específico. Poderá ser uma pessoa física ou, até mesmo, uma etapa automatizada de processamento.

• Para cada atividade são definidos papéis claros e as pessoas conhecem as suas res-ponsabilidades, assim como o que é esperado delas.

• Podem ser usadas referências de performance, a fim de encorajar e acompanhar o melhoramento das atividades processuais.

Page 226: Analista de Sistema Operacional

44 Gerenciamento de Serviços de TI na Prática

• Atividades comuns com o mesmo resultado para diferentes departamentos podem ser controladas de melhor forma se houver sido identificado um processo global para elas.

• Cada processo individualmente é mais bem-gerido do que um processo global para todas as atividades de uma área de TI.

• Os processos abrangem o que é necessário fazer, enquanto os procedimentos cobrem como deve ser feito.

Os processos têm características próprias conforme o segmento de indústria analisado. A atuação da área de TI pode ser classificada como pertencente à indústria de serviço, independentemente do segmento de indústria em que a organização, na qual está in-serida, atua. Assim, evidencia-se na Tabela 1.5 as diferenças entre as características dos processos na indústria de serviços e na indústria de manufatura, de modo a pontuar o trabalho a ser desenvolvido pela área de TI, quando da definição e do gerenciamento de seus processos.

Tabela 1.5 – Diferenças entre a indústria de manufatura e a indústria de serviços

Característica Indústria de serviço Indústria de manufaturaPropriedade (identificação do responsável)

Tende a ser ambígua ou o processo tem vários donos Definição geralmente clara

Fronteiras (pontos inicial e final) Pouco nítidas e difusas Claramente definidas

Pontos de controle (regulam a qualidade e fornecem feedback) Freqüentemente não existem Estabelecidos de forma clara

e formalMedições (base estatística do funcionamento)

Difícil de definir, geralmente não existem Fáceis de definir e gerenciar

Ações corretivas (correção de variações)

Em geral ocorrem de forma reativa

Muito freqüente as ações preventivas

A utilização do conceito de processos5 oferece um conveniente nível de análise, menos detalhado que o do estudo do trabalho, mas muito mais descritivo que o modelo da caixa-preta6. Além disso, permite uma visão melhor do comportamento gerencial, mais integrada e abrangente. É indispensável também para possibilitar a análise adequada dos processos estratégicos e de suporte, tão importantes para o funcionamento dos processos essenciais da área de TI, conforme proposto pela arquitetura de processos descrita na metodologia IT Flex®.

5 Maiores detalhes sobre a abordagem por processos podem ser obtidos pela consulta ao artigo intitulado “Processos, que Processos?” de José Ernesto Lima Gonçalves, referenciado como Gonçalves, 2002.

6 Artigo “The processes of organization and management”, de David Garvin, publicado na SloanManagementReview, v. 39, n. 4, summer 1998.

Page 227: Analista de Sistema Operacional

45Capítulo 1 • Introdução

1.8 Serviço

Não existe uma única definição de serviço. Assim, apresentam-se, a seguir, cinco defini-ções de serviço, de diferentes autores, visando subsidiar a elaboração de uma definição pertinente à área de TI:

• “Atividades, benefícios ou satisfações que são colocados à venda ou proporcionados em conexão com a venda de bens” (American Marketing Association, 1960).

• “Quaisquer atividades colocadas à venda que proporcionem benefícios e satisfa-ções valiosas; atividades que o cliente prefira ou não possa realizar por si próprio” (Bessom, 1973).

• “Uma atividade colocada à venda que gera benefícios e satisfações, sem levar a uma mudança física na forma de um bem” (Stanton, 1974).

• “Qualquer atividade ou benefício que uma parte possa oferecer a uma outra, que seja essencialmente intangível e que não resulte propriedade de alguma coisa. Sua produção pode ou não estar ligada a um produto físico” (Kotler, 1988).

• “Serviço ao cliente significa todos os aspectos, atitudes e informações que ampliem a capacidade do cliente de compreender o valor potencial de um bem ou serviço essencial.” (Uttal e Davidow, 1991).

Das definições expostas, pode-se entender que um serviço é uma ação executada por alguém ou por alguma coisa, caracterizando-se por ser uma experiência intangível, produ-zido ao mesmo tempo em que é consumido, não podendo ser armazenado, e apresentando sérias dificuldades para ser produzido em massa ou atender mercados de massa.

Uma possível definição de serviço de TI é: um conjunto de recursos, TI e não-TI, mantidos por um provedor de TI, cujo objetivo é satisfazer uma ou mais necessidades de um cliente (áreas de negócio) e suportar os objetivos estratégicos do negócio do cliente, sendo percebido pelo cliente como um todo coerente.

Na ITIL, um serviço de TI é definido como “um ou mais sistemas de TI que habilitam um processo de negócio”, devendo-se levar em conta que um sistema de TI é uma combi-nação de hardware, software, facilidades, processos e pessoas.

As características que diferenciam os serviços dos produtos são: a intangibilidade, a indivisibilidade, a variabilidade e a perecibilidade. Ademais, o critério de satisfação é diferente, e o cliente participa desse processo. Quem presta serviços precisa entender per-feitamente essas características e a maneira como elas afetam as organizações.

A intangibilidade dos serviços significa que eles não podem ser observados, provados, apalpados, ouvidos ou cheirados antes de serem adquiridos. As pessoas que se submetem à cirurgia plástica, por exemplo, não podem observar plenamente os resultados antes de contratar a operação; quem move um processo legal não poderá saber o resultado antes

Page 228: Analista de Sistema Operacional

46 Gerenciamento de Serviços de TI na Prática

do julgamento; a pessoa que contrata um arquiteto não receberá os planos completos antes de formalizar a transação.

O resultado disso é que os clientes tentam reduzir a incerteza, procurando sinais da qualidade do serviço e tirando conclusões a partir das comunicações que recebem e das evidências concretas, obtidas dos participantes, dos processos utilizados e das tecnologias empregadas, conforme mostra a Figura 1.13. A área de TI precisa oferecer uma representação tangível que comunique o processo e os prováveis resultados do serviço que irá prestar.

Serviço

Processo TecnologiaPessoas

Figura 1.13 – Composição de um serviço.

A indivisibilidade, por sua vez, significa que os serviços não podem ser separados do seu prestador e da maneira como o mesmo é percebido – seu profissionalismo, sua apa-rência e sua conduta –. Ambos serão utilizados na avaliação da qualidade da organização prestadora do serviço. Essa indivisibilidade abrange as pessoas que atendem ao telefone ou trabalham como recepcionistas da organização. Essas pessoas oferecem com freqüência a primeira impressão que os clientes em perspectiva têm da organização de serviços.

A variabilidade advém da qualidade dos serviços prestados, os quais são inseparáveis das pessoas, enquanto a qualidade, por sua vez, pode variar. O melhor advogado pode cometer um engano; o melhor contador pode esquecer um número e o melhor médico pode estar enfrentando um dia ruim. As implicações da variabilidade dos serviços são geométricas.

Por isso, o prestador de serviços deve-se antecipar em relação aos processos em que existe maior probabilidade de erros, além de criar medidas corretivas com o objetivo de conservar a confiança do cliente, que sofre com o erro.

A perecibilidade dos serviços significa que eles não podem ser armazenados para venda ou utilização posterior. Alguns médicos cobram as consultas que os pacientes perdem, porque o valor do serviço existia apenas naquele momento e desapareceu quando o pa-ciente não compareceu no horário marcado.

A perecibilidade dos serviços também tem certas implicações. Uma delas é que o prestador do serviço está vendendo basicamente seu desempenho. Embora se saiba, por exemplo, que um determinado médico realizou mais de mil cirurgias torácicas, o essencial realmente é que ele realize a cirurgia do cliente que será seu próximo paciente com toda a segurança.

Antes de comprar um produto, o cliente pode avaliar o que está adquirindo. Antes de comprar um automóvel, por exemplo, ele pode dirigi-lo durante um test-drive. Mas os

Page 229: Analista de Sistema Operacional

47Capítulo 1 • Introdução

serviços são diferentes. Primeiro eles são vendidos, para serem, em seguida, produzidos e consumidos simultaneamente.

Ninguém poderá estar certo de que um arquiteto entendeu as necessidades do cliente, até que sejam entregues as plantas do imóvel a ser construído. Em alguns casos, o cliente nunca saberá se os serviços que recebeu foram realmente bons. Uma pessoa que tenha ma-chucado o joelho, por exemplo, em um acidente de esqui, e seja submetida a uma cirurgia, nunca saberá se os exercícios de reabilitação não teriam sido uma melhor solução.

Da mesma maneira, se um advogado sugerir estabelecer um acordo, antes que o processo vá a julgamento, o cliente nunca saberá que resultados a outra opção poderia ter trazido.

1.9 Ciclo de vida de um serviço de TI

Em cada uma das fases do ciclo de vida de um serviço de TI, perguntas devem ser feitas e respondidas de modo a ter-se o acompanhamento da vida do serviço. Estas perguntas são as seguintes:

• Fase de requisição

• Qual é o serviço necessário?

• Por que ele é necessário?

• Qual a quantidade demandada?

• Fase de aquisição

• Onde o serviço será solicitado?

• Onde o serviço será provido?

• Quanto será pago pelo serviço?

• Fase de utilização

• Como o serviço será usado?

• Como validar o serviço provido?

• Como o serviço será restabelecido em caso de falha?

• Fase de desativação

• Quanto está sendo gasto para manter o serviço?

• Qual o retorno que o serviço proporcionou?

• Há uma nova opção?

Page 230: Analista de Sistema Operacional

48 Gerenciamento de Serviços de TI na Prática

1.10 Definição do valor de um serviço de TI

No âmbito do Gerenciamento de Serviços de TI, o valor de um serviço pode ser medido por quatro parâmetros:

• Alinhamento estratégico com o negócio – Grau em que o serviço de TI está alinhado com as atuais e as futuras necessidades do negócio.

• Custo – Valor monetário desembolsado pela disponibilização do serviço de TI e em cada interação.

• Qualidade – Nível de atendimento do serviço de TI em relação aos Acordos de Nível de Serviço (Service Level Agreement – SLA) e Acordos de Nível Operacional (Operational Level Agreement – OLA), estabelecidos externa e internamente à área de TI, respectivamente.

• Independência em relação ao tempo – Capacidade da área de TI em reagir a de-mandas de suporte e em atender às mudanças planejadas em relação ao serviço de TI disponibilizado.

A abordagem para a maximização do valor dos serviços de TI deve envolver a integração dos diferentes componentes de um serviço de TI (pessoas, processo e tecnologia) entre si e também com os objetivos estratégicos fixados pela organização, conforme ilustrado na Figura 1.14.

Cultura, Atitude,Crenças e Capacidade

Infra-Estrutura(incluindo aplicações)

Entradade Serviços e

Suporte a Serviços

Pessoas

TecnologiaProcessos

EstratégiaCondução

DireçãoIntegração

Figura 1.14 – Integração entre os componentes de um serviço de TI.

1.11 Qualidade do serviço de TINo passado recente, a área de TI poderia dar-se ao luxo de focar internamente apenas aspectos técnicos dos diferentes serviços que entregava para a organização, pois era um

Page 231: Analista de Sistema Operacional

49Capítulo 1 • Introdução

setor extremamente especializado e de poucos iniciados. Atualmente, as organizações têm elevadas expectativas em relação à qualidade dos serviços de TI, e tais expectativas tornaram-se dinâmicas, mudando de forma acelerada com a passagem do tempo. Assim, a área de TI necessita viver além destas expectativas, concentrando-se na qualidade dos serviços e na abordagem orientada ao cliente.

O primeiro passo em direção à qualidade dos serviços de TI é aclarar os papéis e a terminologia dos termos “cliente”, “usuário” e “fornecedor”.

• Cliente – Destinatário de um serviço de TI, sendo normalmente o responsável pela alocação dos recursos financeiros para o seu pagamento, diretamente, mediante cobrança, ou indiretamente, pela demonstração em termos de necessidades do negócio (valor do serviço de TI para a organização).

• Usuário – Pessoa que utiliza o serviço de TI diariamente.

• Fornecedor – Entidade responsável pela prestação do serviço de TI.

Qualidade do serviço é um conceito que ganhou grande aplicação prática com a indústria de telecomunicações. A necessidade do seu estabelecimento surgiu quando da integração das diferentes redes nacionais de telecomunicações, operadas por diferentes organizações e sob tecnologias díspares. Nesse momento, verificou-se a necessidade de assegurar aos clientes de cada operadora um nível de serviço adequado, não importan-do para qual país se destinasse a ligação telefônica realizada. As negociações em todo o estabelecimento deste nível de serviço resultaram na definição da expressão Quality of Service – QoS pelo ITU-T7 (o antes usado CCITT):

“Efeito coletivo do comportamento do serviço, o qual determina o grau de satisfação do usuário”.

Observe que, segundo a definição do ITU-T, a qualidade de um serviço é caracterizada por aspectos combinados de comportamento (desempenho) que resultam na satisfação do cliente, pois na área de telecomunicações, na maioria das vezes, o usuário é também o cliente. Sendo assim, o desafio da qualidade na área de serviços é definir quais os atributos de desempenho de um serviço influenciam na satisfação do seu cliente.

1.12 Desafio da qualidade do serviço de TINo Gerenciamento de Serviços de TI é necessário equilibrar as necessidades dos clientes e usuários com a capacidade disponível e os custos definidos pelo negócio. Por exemplo, os usuários de uma área, funcionários de uma área de negócio, podem exigir uma maior disponibilidade dos serviços de TI que utilizam para desempenhar suas funções, en-quanto o cliente, diretor das áreas de negócio, pode estar buscando uma melhor relação custo/benefício (melhor retorno para o dinheiro gasto) e, portanto, distintos níveis de disponibilidade para cada um dos serviços de TI que atendem à sua área.

7 ITU-T – International Telecommunication Union. Acesso v ia Internet pela U R L: http://www.itu.int/itu-t

Page 232: Analista de Sistema Operacional

50 Gerenciamento de Serviços de TI na Prática

Os clientes são geralmente atendidos por um Gerente de Serviço de TI (integrante da equipe de Gerenciamento do Nível de Serviço) ou Gerente de Atenção ao Cliente, enquanto os usuários são atendidos pela equipe da Central de Serviços.

Na prestação de serviços de TI, bem como na indústria de serviços em geral, é muito mais difícil definir qualidade e mantê-la do que na indústria manufatureira, pois:

• cada cliente é diferente;

• o resultado de muitos serviços são intangíveis;

• os serviços são produzidos e consumidos simultaneamente;

• os usuários estão presentes enquanto o serviço é realizado.

Além dos motivos já citados, a indústria de serviços, onde está inserida a área de TI, exige mão-de-obra intensiva, enquanto na indústria manufatureira geralmente é exigido capital intensivo devido aos equipamentos, instalações, estoque de matéria-prima, nível de automatização e escala de produção. O fato do uso de mão-de-obra intensiva torna o trabalho de padronização do comportamento dos serviços de TI uma tarefa árdua, a qual necessitará forte apoio da área de processos, visando garantir a previsibilidade e a conseqüente percepção de consistência por parte dos usuários dos serviços de TI.

O desafio na área de TI é definir quais os atributos dos seus serviços são valorizados pelos seus clientes e usuários. Nesta busca, o Método Kano é uma ferramenta valiosa.

A idéia subjacente ao Método Kano é descobrir quais atributos de um serviço ou produto influenciam na satisfação do cliente, a partir da descoberta da motivação deste cliente em pagar mais ou menos pelo produto ou serviço oferecido.

O professor Noriaki Kano, após estudar o comportamento de inúmeros produtos em relação à satisfação dos seus clientes, definiu três tipos de fatores:

• Fatores básicos (necessários) – São as exigências mínimas que causarão o des-contentamento se não forem cumpridas, mas não causam a satisfação do cliente se forem cumpridas (ou então excedidas). O cliente considera estes fatores como pré-requisitos para a decisão de compra do produto ou serviço. Os fatores básicos estabelecem a entrada, “ponto inicial”, do mercado.

• Fatores competitivos – São os fatores que causam a satisfação se o desempenho for elevado e provocam o descontentamento se o desempenho for baixo. Aqui, a satis-fação é linear em relação ao desempenho. Tais fatores são conectados diretamente às necessidades explícitas dos clientes e aos seus desejos. A organização produtora do produto ou serviço deve tentar ser competitiva.

• Fatores de excitamento (diferenciais) – São os fatores que aumentam a satisfação de cliente, se entregues, mas não provocam descontentamento, caso não forem en-tregues. Tais fatores surpreendem o cliente e geram o “prazer”. Usando estes fatores, uma organização pode realmente distinguir-se de suas concorrentes de uma maneira positiva perante o seu mercado-alvo.

Page 233: Analista de Sistema Operacional

51Capítulo 1 • Introdução

Na Figura 1.15, são apresentados os tipos de fatores definidos por Noriaki Kano de forma gráfica.

Satisfação do Cliente

Desempenho

Excitação(Diferencial)

Linear(Competitivo)

Básico(Necessário)

Figura 1.15 – Fatores do método Kano (Berger, 1993).

No desenvolvimento de um serviço de TI, deve-se ter em mente que fatores são vistos pelos clientes como necessários, competitivos e diferenciais. Para tanto, a técnica proposta é a elaboração de avaliações que permitam saber o grau de necessidade de cada atributo do serviço de TI e, ao mesmo tempo, quanto o cliente valoriza o atendimento desta ne-cessidade, ou seja, quanto ele está disposto a desembolsar para ter a necessidade atendida no grau desejado. Exemplificando:

• Serviço – Correio eletrônico corporativo.

• Atributo – Alta disponibilidade (24 horas por dia x 7 dias por semana).

1) Qual o grau de necessidade de alta disponibilidade do serviço de correio ele-trônico corporativo?

|--------------------|--------------------|-------------------|-------------------|

1 2 3 4 5

Muito baixo Muito alto

2) Qual o grau de contribuição para a sua atividade da alta disponibilidade do serviço de correio eletrônico corporativo?

|--------------------|--------------------|-------------------|-------------------|

1 2 3 4 5

Muito baixo Muito alto

É importante destacar que as necessidades dos clientes mudam com o passar do tempo. Desta forma, atributos classificados como fatores diferenciais, pelos quais os clientes não

Page 234: Analista de Sistema Operacional

52 Gerenciamento de Serviços de TI na Prática

pagariam a mais para ter no serviço prestado hoje, podem passar a ser fatores competitivos amanhã e tornarem-se fatores necessários daqui a seis meses, conforme ilustra a Figura 1.16. Como exemplo desta evolução, reflita sobre a seguinte questão:

Você compraria um microcomputador sem uma interface USB (Universal Serial Bus)?

Resposta:

• Há dois anos, certamente. Uma interface USB era apenas uma novidade, sem muita utilidade prática.

• Há seis meses, talvez sim, talvez não, pois já começava a disponibilidade no mercado de periféricos compatíveis com USB a preços razoáveis, e, portanto, a decisão era calcada na utilização ou não destes periféricos e na quantidade desejada.

• Hoje, já é um fator básico, preferencialmente localizado na parte frontal do micro-computador, haja vista a difusão de pen drivers e máquinas fotográficas digitais com conectores USB.

Satisfação do Cliente

Desempenho

Excitação(Diferencial)

Linear(Competitivo)

Básico(Necessário)

Tempo

Figura 1.16 – Evolução dos fatores de um serviço ou produto (Berger, 1993)

1.13 Medida da qualidade

Na indústria manufatureira, medir a qualidade dos produtos produzidos é fácil, conside-rando-se o quanto em tempo isto já é estudado e posto em prática, pois:

• As medidas são bem-definidas.

• Existe a possibilidade de comparações.

• Existem melhores práticas.

• Existem sistemas de acompanhamento.

Page 235: Analista de Sistema Operacional

53Capítulo 1 • Introdução

Já na indústria de serviços, a tarefa de medir a qualidade não é tão simples quanto na indústria de manufatura, pois:

• Tudo é muito novo.

• Os serviços são abstratos.

• Padrões não estão disponíveis.

• Alto nível de personalização.

Para exemplificar, suponha que você e sua família decidiram realizar uma viagem, e, para alcançar o destino traçado, escolheram uma rodovia privatizada. Você está dirigindo o auto-móvel e, de repente, ocorre uma falha mecânica em seu carro, impossibilitando a continuação da viagem. O que lhe vem à mente ao encontrar a placa mostrada na Figura 1.17.

Emergência

180km adiante

Figura 1.17 – Qualidade do serviço.

A impressão é de um péssimo serviço de emergência. Entretanto, neste momento, você é usuário ou cliente do serviço de emergência oferecido pela concessionária da rodovia? Você é o usuário, não o cliente. Ao escolher uma rodovia para a sua viagem, o correto era ter-se informado sobre as condições em que os diversos serviços oferecidos pela concessionária seriam prestados, uma vez que o cliente é o poder público que realizou a privatização da rodovia e celebrou com a concessionária vencedora do processo os serviços e os níveis de serviço associados, que seriam oferecidos aos usuários da rodovia. Mesmo sendo um absurdo, pode ser que o nível de serviço representado pela placa mostrada esteja dentro do acordado entre fornecedor e cliente, ou seja, concessionária e governo.

A qualidade de um serviço pode ser determinada pelo nível de satisfação do cliente em relação a ele, ou seja, como o cliente percebe o serviço previsto/entregue. Entretanto, a percepção do cliente também é influenciada pelas suas expectativas em relação ao ser-viço. Para determinar o nível de satisfação do cliente, é necessário saber que existem cinco fatores que influenciam a avaliação de um serviço, os quais são apresentados em conjunto com suas relações na Figura 1.18 e descritos a seguir8:

8 No detalhamento do processo de gerenciamento de nível de serviço (ServiceLevelManagement – SLM), os diferentes tipos de serviço e os hiatos entre eles serão tratados em profundidade.

Page 236: Analista de Sistema Operacional

54 Gerenciamento de Serviços de TI na Prática

• Serviço esperado – É o que o cliente espera receber em troca do valor pago pelo serviço.

• Serviço adequado – É o que atende às necessidades expressas pelo cliente.

• Serviço desejado – É o que o cliente deseja receber a mais do que ele expressou necessitar.

• Serviço previsto – É o que o cliente recebe em termos de serviço, ou seja, o acordado com o fornecedor.

• Serviço percebido – É como o cliente percebe o serviço prestado, considerando suas expectativas em relação ao que entende ser o serviço adequado e o serviço desejado.

Serviço Esperado

Serviço Previsto

Percepção deSuperioridadedo Serviço

Percepção deAdequaçãodo Serviço

Faixa de Tolerância

SatisfaçãoServiço Percebido

Serviço Desejado

Serviço Adequado

Figura 1.18 – Modelo conceitual da avaliação de serviços.

O ideal para a satisfação do cliente é que o serviço previsto fosse igual àquele percebido e este, por sua vez, igual ao esperado. Entretanto, tal situação é quase impossível de ocorrer na prática, pois existem limitações de custo e necessidades de adequação à estratégia de negócio, que podem variar de uma organização para outra.

1.14 Necessidade, expectativa e desejo

As necessidades e expectativas dos clientes freqüentemente são muito diferentes. Na maioria dos casos, as necessidades são muito mais fáceis de satisfazer do que as expectativas. Os clientes tendem a comunicar e a preparar as suas especificações de serviços e produtos de TI a serem adquiridos baseados em suas necessidades, mas medem o desempenho da área TI que os atende baseados em suas expectativas. Por exemplo, quando se pergunta a um cliente o que ele precisa em um determinado serviço de e-mail, ele irá responder que necessita da disponibilidade e da sua capacidade de armazenamento de mensagens, mas o que ele espera, além disso, é velocidade no acesso, rápido suporte técnico em caso de necessidade de ajuda e um baixo tempo de reparo, quando ser fizer necessária uma ação corretiva, não importando se no ambiente do servidor ou em sua estação local, indepen-dentemente de onde estejam localizados.

Page 237: Analista de Sistema Operacional

55Capítulo 1 • Introdução

O atendimento das necessidades é freqüentemente verificado pela criação de indicadores de desempenho associados às variáveis de desempenho importantes para as necessidades existentes, fixando-se metas com uma faixa de variação determinada, mas o que realmente deseja o cliente é que todas as interações estejam próximas da média estabelecida, e não apenas dentro da faixa de tolerância, garantindo a uniformidade de resposta a sucessivas interações, o que pode ser traduzido como previsibilidade.

Observe a Figura 1.19 e defina com qual dos dois pilotos você gostaria de voar em sua próxima viagem de férias com sua família.

Ambos com amesma

especificaçãoe com amesmamédia

Piloto A Piloto B

Figura 1.19 – Resultado da pesquisa de satisfação.

O piloto B apresenta um resultado com menor variabilidade (Figura 1.20), sendo, então, mais previsível que o piloto A, ou seja, o desempenho do piloto B é mais homogêneo e consistente do que o do A, o que acaba por incutir a sensação de maior confiança ao voar com o piloto B.

Distribuição do Piloto A(maior variabilidade)

Distribuição do Piloto B(menor variabilidade)

Figura 1.20 – Distribuição estatística dos resultados.

Dependendo da variabilidade dos resultados em relação aos limites de controle, o estado de um processo pode ser assim denominado, conforme ilustrado na Figura 1.21:

• Caos – O processo apresenta comportamento instável, com alta variabilidade de resultados, fazendo com que os limites de controle estejam fora da faixa de valores especificada.

Page 238: Analista de Sistema Operacional

56 Gerenciamento de Serviços de TI na Prática

• Deixando o caos – O processo apresenta comportamento instável, com alta varia-bilidade de resultados; entretanto, os resultados estão compreendidos dentro da faixa de valores especificada.

• Melhorável – O processo apresenta comportamento estável, com baixa variação de resultados; entretanto, os resultados estão compreendidos fora da faixa de valores especificada.

• Ideal – O processo apresenta comportamento estável, com baixa variação de resulta-dos, e os resultados estão compreendidos dentro da faixa de valores especificada.

Limites Especificados

Limites de Controle

Melhorável

Estável mas não capaz

Ideal

Estável e capaz

Caos

Instável e não capaz

Deixando o Caos

Capaz mas instável

Figura 1.21 – Estados de um processo.

O grande objetivo é tornar todos os processos da área de TI passíveis de melhora9, pois não há como garantir que melhorias implementadas em processos não-capazes (instáveis) perdurem. Só se pode melhorar aquilo que é de alguma forma previsível, ou seja, cujos resultados, mesmo que não os desejados, possam ser previstos, permitindo constatar o efeito produzido pela melhoria implementada.

A área de TI deve se certificar de que entende as necessidades e expectativas dos seus clientes, bem como os possíveis desejos destes, procurando, ao prestar os serviços solici-tados, atender às necessidades de acordo com as expectativas dos clientes e garantindo que os mesmos tenham a total percepção do atendimento, o que é indicado pelo nível de satisfação da clientela.

9 Para este intento, propõe-se a utilização da metodologia Six Sigma.

Page 239: Analista de Sistema Operacional

57Capítulo 1 • Introdução

1.15 Satisfação do cliente

O nível de satisfação do cliente com determinado serviço ou produto é diretamente proporcional à diferença entre o desempenho percebido (não o desempenho real) e o desempenho previsto (as expectativas do cliente e não as necessidades dele). Nas relações atuais, as expectativas dos clientes estão continuamente aumentando e se alterando. O notável desempenho de ontem apenas cumpre os requisitos de hoje e será, com toda a certeza, insuficiente amanhã.

As chaves para a satisfação do cliente são:

• Serviços e produtos superiores.

• Equipe de venda e entrega de serviços e produtos altamente capacitada.

• Processos de suporte rápidos, baratos e eficazes.

O cliente de serviços de TI necessita:

• Especificação – Saber de antemão o que se irá receber.

• Conformidade – A solução deve atender à especificação.

• Consistência – A cada interação o comportamento deve ser idêntico.

• Mais valor pelo seu dinheiro – O preço pago deve ser justo pelo produto ou serviço recebido.

• Comunicação – Desejo de saber o que, quando, como e o que fazer.

De modo geral, a área de TI não apresenta um nível de suporte ao cliente adequado em razão de diversos problemas, conforme se indica a seguir:

• Inexistência de um mecanismo efetivo de suporte ao cliente.

• Baixa confiança por parte do cliente.

• Recursos de suporte envolvidos com a solução de problemas do dia-a-dia.

• Resolução de incidentes repetidos, em vez de uma solução permanente.

• Interrupções constantes nos serviços, devido à dependência de pessoal-chave.

• Ocorrência de mudanças não-coordenadas nem registradas.

• Inabilidade de lidar com as mudanças do negócio, principalmente com o aspecto da velocidade.

• Recursos e custos pouco claros.

• Desempenho inconsistente.

• Pouca informação para gestão disponível.

Page 240: Analista de Sistema Operacional

58 Gerenciamento de Serviços de TI na Prática

A ITIL vem ao encontro do problema da baixa satisfação dos clientes com os serviços da área de TI, preocupando-se em alinhar as expectativas dos clientes à capacidade de atendimento da área de TI e às necessidades da estratégia de negócio da organização, propondo melhores práticas para a definição e o gerenciamento dos processos de entrega e suporte de serviços de TI, visando garantir a estabilidade, consistência, qualidade e baixo custo de tais serviços.

1.16 Melhoria contínua

As organizações da indústria de serviços manipulam um grande número de transações dos seus clientes, fato que potencializa o surgimento de “não-conformidades” e “erros”. Tal fato exige que a área de TI mantenha-se na constante procura do aumento da qualidade dos serviços de TI oferecidos à organização.

O processo de aumento da qualidade é caracterizado por um esforço coletivo e coordenado de melhoria contínua dos serviços de TI prestados para a organização, baseado na introdução de melhorias passíveis de medição de seus resultados em áreas específicas dos processos de trabalho, visando à perpetuação dos resultados, o que permitirá alcançar um novo patamar de desempenho, base para as próximas melhorias, conforme demonstrado na Figura 1.22.

PA

DC

Alinhamentocom o

Negócio

Matu

ridad

e

Tempo

Melhoria Contínua

Efetivas Melhoras da Qualidade

Consolidação do Nível Conseguido(exemplo: ISO 9001)

Figura 1.22 – Processo de melhoria contínua.

A metodologia recomendada pela ITIL para realização do processo de melhoria con-tínua dos serviços da área de TI é a PDCA (Plan, Do, Check and Act), desenvolvida por William Eduards Deming10 e amplamente propagada pela indústria manufatureira. Esta metodologia é constituída, conforme seu nome indica, de quatro passos:

10 Considerado um herói pelo povo japonês em razão de sua contribuição para a melhoria da qualidade da indústria manufatureira do Japão. Faleceu em 1993, aos 93 anos de idade.

Page 241: Analista de Sistema Operacional

59Capítulo 1 • Introdução

• Plan – Planejar as ações a serem executadas.

• Do – Realizar as ações planejadas.

• Check – Verificar o que foi feito em relação ao que foi planejado.

• Act – Atuar corretivamente sobre a diferença identificada.

O objetivo do processo de melhoria contínua na área de TI é fazer com que os clientes não vão embora, ou seja, procurem outros fornecedores de serviços de TI externos à or-ganização, pois, conforme as palavras de Deming, “clientes insatisfeitos não se queixam; mudam de fornecedor”.

1.17 Gerenciamento de Serviços de TI

O Gerenciamento de Serviços de TI é, de forma resumida, o gerenciamento da integração entre pessoas, processos e tecnologias, componentes de um serviço de TI, cujo objetivo é viabilizar a entrega e o suporte de serviços de TI focados nas necessidades dos clientes e de modo alinhado à estratégia de negócio da organização, visando o alcance de objetivos de custo e desempenho pelo estabelecimento de acordos de nível de serviço entre a área de TI e as demais áreas de negócio da organização. Isto pode ser realidade, independen-temente do tipo ou tamanho da organização, seja ela governamental, multinacional, um fornecedor de serviços de TI por outsourcing, ou um ambiente de escritório com apenas uma pessoa responsável pelos serviços de TI.

O Gerenciamento de Serviços de TI deve garantir que a equipe de TI, com a execução e gerenciamento dos diversos processos de TI, entregue os serviços de TI dentro do acordado, em termos de custo e de nível de desempenho, com as áreas de negócio da organização, não se esquecendo de atender paralelamente aos objetivos estratégicos definidos para ela. Para tanto, é necessário o estabelecimento do ponto na “Fronteira da Eficiência” onde se deseja chegar (ponto A), diagnosticar o ponto atual (ponto B) e estabelecer o plano de ação que conduzirá a transformação do desempenho atual no desempenho desejado, conforme mostra a Figura 1.23.

Uma vez estabelecido o plano de ação, é necessário que, ao longo de sua execução, a área de TI preocupe-se em garantir os mecanismos adequados para o Gerenciamento de Serviços de TI, haja vista a extrema necessidade atual de controlar os processos de TI e como eles afetam o desempenho dos serviços de TI disponibilizados para a organização, evoluindo em sua maturidade no processo de Gerenciamento de Serviços de TI, conforme demonstra a Figura 1.24.

Page 242: Analista de Sistema Operacional

60 Gerenciamento de Serviços de TI na Prática

Custo

Nível de Serviço Alto

Baixo

Melhor Prática

Menos que a Melhor Prática

A

B

BaixoAlto

Figura 1.23 – Fronteira da eficiência.

Fonte: Michael Porter, What is Strategy? Harvard Business Review, nov.-dec. 1996.

Início da Jornada...1 Início

Genérico2 Medição Operacional

Estendido3 Controle Operacional

Superado4 Controle do Serviço

Excelente5 Melhoria Contínua

Executar e medir

Conseguir o “Ajuste Interno”

Conseguir o “Ajuste Externo”

Implantar Auto-gestão

Figura 1.24 – Evolução da maturidade do Gerenciamento de Serviços de TI.

Para alcançar os objetivos do Gerenciamento de Serviços de TI, a área de TI deve passar a:

• Contribuir de forma estratégica com o negócio.

• Permitir a medição de sua contribuição para o negócio.

• Entregar serviços mais consistentes e estáveis.

• Dar menor ênfase na tecnologia.

Os fatores motivadores para a adoção do Gerenciamento de Serviços de TI são, atu-almente:

• Exigência do incremento do profissionalismo.

Page 243: Analista de Sistema Operacional

61Capítulo 1 • Introdução

• Enfoque na entrega de benefícios para os clientes e para a organização.

• Necessidade de indicadores de desempenho para a tomada de decisão.

• Definição de pontos de contato claros entre TI e as áreas clientes.

• Redução de custos dos processos de TI.

• Evitar a reinvenção da roda, pela a adoção das melhores práticas reunidas na ITIL.

• Sobreviver a longo prazo.

1.18 Introdução à ITIL

Em um mundo altamente competitivo, de mudanças constantes e inesperadas, é preciso ter flexibilidade e agilidade suficientes para reagir com rapidez às falhas e aos imprevistos, assim como estar preparado também para se antecipar a eles. Somam-se a isso as novas iniciativas da organização, os lançamentos de produtos e as campanhas que precisam contar com a competência e velocidade da área de TI a fim de serem bem-sucedidas e eficazes.

O desafio de gerenciar uma área de TI, embora há muito tempo do interesse da comu-nidade de TI, tornou-se recentemente uma preocupação da alta direção das organizações. O alinhamento estratégico da área de TI com o negócio está agora realçado, bem como as abordagens ao Gerenciamento de Serviços de TI, conforme demonstrado. Sendo assim, é necessária uma abordagem ampla em relação ao gerenciamento da área de TI, de modo a refletir verdadeiramente suas as atividades, responsabilidades e contribuições perante a organização.

As disciplinas relacionadas com o Gerenciamento de Serviços de TI, que buscam esse alinhamento dinâmico da área de TI com o negócio, receberam um reforço substancial com o estabelecimento da ITIL, um conjunto de melhores práticas para o Gerenciamento de Serviços de TI. Tal padrão elevou essas disciplinas a uma nova ordem de grandeza em termos de qualidade, segurança e confiabilidade de processos, situação comprovada pela maior parte das organizações usuárias de TI que as adotaram.

As melhores práticas reunidas na ITIL fornecem uma alternativa para o Gerenciamen-to de Serviços de TI, pela proposição de uma metodologia de gerenciamento focada nos processos e nas suas relações de dependência. A ITIL fornece orientações para a área de TI baseadas nas melhores práticas e em um ambiente de qualidade, visando à melhoria contínua, envolvendo pessoas, processos e tecnologia, objetivando o gerenciamento da área de TI como um negócio dentro do negócio (a organização).

Hoje, a ITIL encontra-se amplamente consagrada como o caminho mais seguro e bem-sucedido para a busca por níveis mais elevados de desempenho no Gerenciamento dos Serviços de TI, trazendo uma visão world class de atendimento para a área de TI, de forma

Page 244: Analista de Sistema Operacional

62 Gerenciamento de Serviços de TI na Prática

alinhada com as áreas de negócio e à estratégia de negócio da organização. Os processos descritos na ITIL abrangem os três estágios fundamentais da evolução do posicionamento da área de TI em relação à sua contribuição para a geração de valor para a organização.

1.19 História da ITIL

A ITIL foi formada no final da década de 1980 pela CCTA (Central Communications and Telecom Agency), atual OGC11 (Office of Government Commerce), como um esforço para disciplinar e permitir a comparação entre as propostas dos diversos proponentes a prestadores de serviços de TI para o governo britânico, haja vista a grande adoção da metodologia de gerenciamento denominada outsourcing e da subcontratação de serviços de TI pelos seus diferentes órgãos, agências e instituições, objetivando garantir um mínimo de padronização de atendimento em termos de processos, terminologia, desempenho, qualidade e custo.

Durante a década de 1990, as práticas reunidas na ITIL passaram a ser adotadas pelas organizações européias privadas, uma vez que a ITIL foi concebida como um padrão aberto, sobretudo pelo grande enfoque em qualidade, garantido pela definição de processos e a proposição de melhores práticas para o Gerenciamento dos Serviços de TI, viabilizando a aderência à prática ISO 9.000 e ao modelo de referência da European Foundation for Quality Management (EFQM). Com o avançar dos anos, a ITIL passou a ser também utilizada pelos países da América do Norte, tornando-se o “padrão de fato” da atualida-de no segmento de TI. Hoje, a ITIL é conhecida e utilizada por organizações públicas e privadas de países de todo o mundo, tendo como previsão de adoção o seguinte quadro, em pesquisa realizada pela Forester Research, para organizações com faturamento igual ou superior a US$ 1 bilhão:

• 13% em 2004.

• 40% em 2006.

• 80% em 2008.

Dentre os fatores motivadores da atual corrida pela adoção das práticas reunidas na ITIL, pode-se citar o incremento dos seguintes aspectos:

• Custos de entrega e manutenção dos serviços de TI.

• Requerimentos da organização em relação à qualidade e ao custo/benefício dos serviços de TI.

• Demanda em obter a medição do retorno dos investimentos em TI.

• Complexidade da infra-estrutura de TI.

• Ritmo de mudanças nos serviços de TI.

11 Acesso via Internet pela URL: http://www.ogc.gov.uk

Page 245: Analista de Sistema Operacional

63Capítulo 1 • Introdução

• Necessidade de disponibilidade dos serviços de TI.

• Aspectos relacionados com a segurança.

Em sua primeira versão, a ITIL era composta de aproximadamente 40 livros, daí o fato de ser conhecida por biblioteca. Entre 2000 e 2002, sofreu uma completa revisão e reformulação, sendo as práticas reunidas em oito volumes, conforme relação a seguir, passando a ser conhecida como a versão 2 da ITIL.

• Service Support (Suporte aos Serviços).

• Service Delivery (Entrega de Serviços).

• Planning and Implemention (Planejamento e Implementação).

• Applications Management (Gerenciamento de Aplicações).

• Security Management (Gerenciamento da Segurança).

• Information and Communication Technology (ICT) Infrastructure Management (Gerenciamento da Infra-Estrutura de TI e de Comunicações).

• Business Perpective (Perspectiva do Negócio).

• Software Asset Management (Gerenciamento dos Ativos de Software).

Para o ano de 2006 estava prevista a disponibilização da versão 3 da ITIL, cujos tra-balhos de elaboração iniciaram-se em 2004. Esta terceira versão trará uma ampliação do escopo da ITIL, tanto do lado do negócio quanto do lado da TI, indo mais a fundo nos procedimentos necessários à área de Tecnologia da Informação.

Atualmente, o esforço de atualização e divulgação da ITIL ao redor do mundo é re-alizado pelo itSMF (Information Technology Service Management Forum), um fórum independente, reconhecido internacionalmente, presente em mais de 32 países, composto por usuários, fornecedores, organizações públicas e privadas e instituições de ensino, independentemente de tamanho ou atuação.

1.20 itSMF Brasil

Desde que iniciou efetivamente suas atividades no país, em 2004, o itSMF Brasil12, versão local do fórum internacional de mesmo nome que desenvolve e promove o conjunto de melhores práticas denominado ITIL em todo o mundo, tem se pautado pelo compromisso de divulgar, debater, incentivar e divulgar a adoção da abordagem proposta pelo conjunto de melhores práticas aplicadas ao Gerenciamento de Serviços de TI.

12 No Brasil, sua sede está localizada em São Paulo, no endereço (quando da elaboração deste livro): itSMF Brasil, Av. Prof. Almeida Prado, 532 IPT – Edifício 53 – 2º. andar Cidade Universitária CEP 05508-901 São Paulo – SP Site no Brasil: http://www.itsmf.com.br, Site internacional: http://www.itsmf.com

Page 246: Analista de Sistema Operacional

64 Gerenciamento de Serviços de TI na Prática

A proposta do itSMF Brasil é tornar-se uma referência para aqueles que necessitam de informações consistentes para a melhoria do Gerenciamento de Serviços de TI. Esta, aliás, tem sido a bandeira do itSMF Brasil, desde que, em dezembro de 2001, dois con-sultores perceberam que faltava um fórum no país voltado para a melhoria dos serviços de TI e decidiram organizar uma representação local do órgão, sob o consentimento da instituição-mãe, o itSMF internacional. Os anos de 2002 e 2003 foram de edificação do relacionamento, de contatos internacionais com os vários fóruns e da montagem do plano de trabalho e dos objetivos e aprovação final pelo itSMF internacional do capítulo (chapter) Brasil.

Para responder ao desafio da implementação da cultura de Gerenciamento de Serviços de TI, a itSMF Brasil vem se estruturando cada vez mais para atender a tais exigências. É claro que para chegar ao nível ótimo do Gerenciamento de Serviços de TI ainda tem-se de percorrer um longo caminho. É um lento processo de amadurecimento que aos poucos vem avançando no Brasil, não restando dúvidas de que isso ocorrerá mais cedo ou mais tarde, seja por pressão externa das novas regulamentações ou por pressão interna das próprias organizações preocupadas com redução de custos e maior eficiência operacional de suas áreas de Tecnologia da Informação.

1.21 ITIL

A ITIL é composta por um conjunto das melhores práticas para a definição dos processos necessários ao funcionamento de uma área de TI, conforme mostra a Figura 1.25, com o objetivo permitir o máximo de alinhamento entre área de TI e as demais áreas de negócio, de modo a garantir a geração de valor à organização.

Suporte aosços

Gerenciamento de Aplicações Gerenciamento de Canaisde Suprimento

Persp

ectiv

as do

Neg

ócio Gerenciamentoda

Infra-Estrutura

Gerenciamento dos Serviços

Entrega de Serviços

Suporte aos Serviços

Planejamento para o Gerenciamento dos Serviços de TI

Fornecedores

Negó

cioTecnologiadaInform

ação

Gerenciamento da Segurança

Figura 1.25 – ITIL.

Page 247: Analista de Sistema Operacional

65Capítulo 1 • Introdução

A ITIL descreve a base para a organização dos processos da área de TI, visando à sua orientação para o Gerenciamento de Serviços de TI. As diversas práticas reunidas descre-vem os objetivos, atividades gerais, pré-requisitos necessários e resultados esperados dos vários processos, os quais podem ser incorporados dentro das áreas de TI.

A ITIL não define os processos a serem implementados na área de TI, mas, sim, demons-tra as melhores práticas que podem ser utilizadas para esta definição. Tais práticas, por sua vez, podem ser adotadas do modo que melhor puder atender às necessidades de cada organização. Por isto, a ITIL pode ser empregada por áreas de TI que já possuam processos orientados ao Gerenciamento de Serviços de TI, orientando-os às melhores práticas.

A adoção da ITIL não obriga a uma nova maneira de pensar e agir. Essa adoção fornece uma base onde colocar os processos existentes em um contexto estruturado, validando suas atividades, tarefas, procedimentos e regras.

Por evidenciar as relações entre os processos da área de TI, qualquer falha de comuni-cação ou falta de cooperação entre as várias funções da área de TI pode ser detectada e eliminada ou minimizada. A ITIL fornece um comprovado guia para o planejamento de processos padronizados, funções e atividades para os integrantes da equipe de TI, com referências e linhas de comunicação apropriadas entre elas.

1.22 Gerenciamento de processos

O Gerenciamento de Serviços de TI baseia-se em processos. Cada um deles é constituído por um conjunto de atividades inter-relacionadas, a partir de um objetivo estipulado, executadas para atingir os resultados desejados. Um processo pode tornar-se bastante complexo, dependendo da organização, sendo que, para cada processo, existe um método de gerenciamento específico. Assim, também deve existir um gerente de processo desig-nado formalmente pela área de TI para coordená-lo. Um determinado processo não deve ser visto como isolado dos outros processos, pois eles estão inter-relacionados, razão pela qual o Gerenciamento de Serviços de TI é necessário, coordenando todos os processos de TI para a obtenção do mesmo objetivo.

Os objetivos do gerenciamento de processos são:

• Aumentar a qualidade dos serviços.

• Aumentar a previsibilidade do comportamento.

• Diminuir o custo alocado.

Os processos de suporte aos serviços de TI e de entrega de serviços de TI descritos pela ITIL podem ser classificados, conforme ilustrado na Figura 1.26, em táticos e operacionais. Os processos responsáveis pela entrega dos serviços de TI (Service Delivery) pertencem ao nível tático, enquanto aqueles responsáveis pelo suporte dos serviços de TI (Service Support) são do nível operacional.

Page 248: Analista de Sistema Operacional

66 Gerenciamento de Serviços de TI na Prática

Missão

Estratégia

Tática

Operações

Alinhamento de TIao Negócio

Suporte aosServiços

Entrega dos Serviços

Figura 1.26 – Posicionamento dos processos da ITIL.

Os processos do nível tático baseiam-se no relacionamento entre a área de TI e os seus clientes (áreas de negócio). Os processos deste nível são particularmente responsáveis por estabelecer e garantir o cumprimento dos acordos efetuados com os clientes, bem como monitorar o atendimento das metas acordadas para o desempenho dos serviços de TI. Já os do nível operacional respondem pela manutenção dos serviços de TI sob as condições acordadas com os clientes.

Em uma implementação da ITIL aos processos da área de TI, muitos procedimentos já existentes são preservados ou adaptados, pois podem já ser a melhor prática para o desenvolvimento daquela tarefa, naquela área de TI.

Os procedimentos envolvem pessoas, que são as responsáveis por certas tarefas que devem ser realizadas segundo os objetivos do processo. As mesmas pessoas podem acumu-lar a responsabilidade pela execução de mais de uma tarefa e a gerente do processo pode auxiliar na coordenação desses recursos, de modo a não comprometer o fornecimento dos serviços de TI que dependem daquele processo.

1.23 Modelo de referência e a ITIL

Como os processos e suas atividades são executados pelas diferentes funções da área de TI, faz-se necessária a identificação de todos os setores da área de TI que deles participam, bem como a definição, como já foi proposto anteriormente, de um gerente específico para a coordenação de cada um. O trabalho com os processos identificados constitui-se em uma novidade para muitas organizações e, portanto, para muitas áreas de TI. Ao definir quais são as atividades do processo, que entradas são necessárias e que resultados podem ser obtidos do processo, é possível trabalhar de modo mais eficiente e eficaz. A medição e a condução das atividades aumentam esta eficácia. Finalmente, pela adição de normas ao processo, é possível adicionar medidas de qualidade ao resultado, obtendo-se a pro-

Page 249: Analista de Sistema Operacional

67Capítulo 1 • Introdução

pagada efetividade para a organização. Estes três pontos reunidos permitirão, na medida certa, a obtenção do quarto ponto desejado, a economicidade, ou seja, a melhor relação custo/benefício para a organização.

Para demonstrar a interatividade entre os processos descritos na ITIL, propõe-se a apresentação de um modelo de referência de processos para a área de TI, conforme de-monstrado na Figura 1.27, onde apresenta o inter-relacionamento entre os processos da ITIL a serem abordados neste livro, destacados com fundo escuro, incluindo a função da Central de Serviços (Service Desk).

Centro de Comando Central de Serviços Gerenciamentode Aplicação

Usuário Cliente

Gerenciamentode Incidente

GerenciamentoFinanceiro

Gerenciamentode Continuidade

Gerenciamentode Relacionamento

Gerenciamentode Capacidade

Gerenciamentode Problema

Gerenciamentode Mudança

Gerenciamento deNível de Serviço

Gerenciamentode Configuração

Gerenciamentode Comunicação

Gerenciamentode Disponibilidade

Gerenciamentode Segurança

Suporte ao Serviço Entrega do Serviço

Área

de T

I

Organização

Gerenciamentode Liberação

Figura 1.27 – Modelo de Referência de Processos de TI13.

O modelo de referência de processos proposto possui duas áreas em que os processos da ITIL são fundamentais para a sua operacionalização plena:

• Suporte ao Serviço (Service Support)

Os processos desta área concentram-se nas tarefas de execução diária, necessárias para a manutenção dos serviços de TI já entregues e em utilização pela organização. São eles:

1. Gerenciamento de Configuração (Configuration Management).

13 Modelo de referência dos processos da área de TI, criado pelos autores, com a inclusão dos principais processos da ITIL

Page 250: Analista de Sistema Operacional

68 Gerenciamento de Serviços de TI na Prática

2. Gerenciamento de Incidente (Incident Management).

3. Gerenciamento de Problema (Problem Management).

4. Gerenciamento de Mudança (Change Management).

5. Gerenciamento de Liberação (Release Management).

• Entrega do Serviço (Service Delivery)

Os processos desta área concentram-se nas atividades de planejamento a longo prazo dos serviços que serão demandados pela organização e na melhoria dos serviços já entregues e em utilização pela organização. São eles:

1. Gerenciamento do Nível de Serviço (Service Level Management).

2. Gerenciamento de Capacidade (Capacity Management).

3. Gerenciamento da Disponibilidade (Availability Management).

4. Gerenciamento da Continuidade dos Serviços de TI (IT Service Continuity Management).

5. Gerenciamento Financeiro (Financial Management).

Além dos processos destas duas áreas principais, descritos na ITIL, o modelo de refe-rência de processos prevê outros relacionados com:

• Gerenciamento de Aplicação (Application Management).

• Gerenciamento da Segurança (Security Management).

• Gerenciamento da Comunicação (Communication Management).

• Gerenciamento do Relacionamento (Relation Management).

Os processos de gerenciamento de aplicação e segurança também fazem parte da ITIL, mas fogem do escopo deste livro. A novidade do modelo de referência de processos proposto é a incorporação dos processos de gerenciamento de comunicação, responsável por todo o movimento de informações entre TI e o negócio, assim como do gerenciamento de relacio-namento, responsável pelo acompanhamento de todo o histórico de interações do cliente e o conseqüente suporte para a tomada de decisão em negociações com o cliente.

Afora os processos, a ITIL descreve a função de Central de Serviços (Service Desk), acrescida da proposição de uma Central de Monitoramento (Command Center).

A ITIL não se limita aos processos nem às funções citadas, compreendendo vários outros aspectos e processos da área de TI, os quais não farão parte deste livro, porque não têm relação direta com os processos pertencentes ao escopo de estudo definido.

Page 251: Analista de Sistema Operacional

69Capítulo 1 • Introdução

1.24 Detalhamento dos processos da ITIL

A seguir, serão descritos os processos da ITIL apresentados no modelo de referência de processos da área de TI.

1.24.1 Gerenciamento de Configuração

É importante para toda organização controlar os seus meios de produção, pois eles são a chave para a criação de produtos ou serviços a serem oferecidos aos clientes, pelos quais se pode criar valor para a organização. Como todos os demais meios de produção, os da área de TI devem ser controlados e gerenciados.

O processo de Gerenciamento de Configuração é o responsável pela criação da base de dados de gerenciamento de configuração (Configuration Management Database – CMDB), a qual é constituída pelos detalhes dos itens de configuração (Configuration Items – CIs) empregados para o aprovisionamento e o gerenciamento dos serviços de TI.

Um item de configuração é um componente que faz parte ou está diretamente relacio-nado com a infra-estrutura de TI. Um item de configuração pode ser um componente físico ou lógico, bem como pode também ser composto por outros itens de configuração.

Alguns exemplos de itens de configuração são:

• microcomputador,

• placa de rede,

• software,

• manual técnico de um equipamento,

• procedimento de trabalho.

1.24.2 Gerenciamento de Incidente

O processo de Gerenciamento de Incidente é responsável pelo tratamento e pela resolução de todos os incidentes observados nos serviços de TI, visando ao restabelecimento dos serviços no menor prazo possível. Para a sua operacionalização, ele se apóia na estrutura da Central de Serviços.

A Central de Serviços é um importante componente do aprovisionamento de serviços de TI para a organização. Ela é freqüentemente o primeiro ponto de contato dos usuários que, ao utilizarem um serviço de TI, percebem alguma coisa diferente do previsto. Os dois principais focos de uma Central de Serviços são o gerenciamento e a comunicação de inci-dentes. Há diferentes tipos de central de serviços, a seleção do mais apropriado para uma dada organização dependerá das necessidades para a implementação de sua estratégia de negócio. Algumas Centrais de Serviço provêm apenas o registro das chamadas e quando

Page 252: Analista de Sistema Operacional

70 Gerenciamento de Serviços de TI na Prática

detectam ser um incidente, transferem a chamada para uma outra equipe mais experiente e capacitada para o atendimento. Outras provêm um alto nível de serviço, possibilitando a resolução de grande parte dos incidentes reportados durante o período do atendimento, enquanto o usuário o está reportando.

1.24.3 Gerenciamento de Problema

O processo de Gerenciamento de Problema é o responsável pela resolução definitiva e prevenção das falhas por trás dos incidentes que afetam o funcionamento normal dos serviços de TI. Isto inclui assegurar que as falhas serão corrigidas, prevenir a reincidência das mesmas e realizar uma manutenção preventiva que reduza a possibilidade de que venham a ocorrer.

1.24.4 Gerenciamento de Mudança

O processo de Gerenciamento de Mudança tem a finalidade de assegurar que todas as mudanças necessárias nos itens de configuração (Configuration Item) serão realizadas conforme planejado e autorizado, o que inclui assegurar a existência de uma razão do negócio subjacente a cada mudança a ser realizada, identificar os itens de configuração envolvidos, testar o procedimento de mudança e garantir a existência de um plano de recuperação do serviço, caso algum imprevisto venha a ocorrer,, como, por exemplo, o bloqueio inesperado de um item de configuração.

1.24.5 Gerenciamento de Liberação

O Gerenciamento de Liberação é o processo responsável pela implementação das mu-danças no ambiente de infra-estrutura de TI, ou seja, pela colocação no ambiente de produção de um conjunto de itens de configuração novos e/ou que sofreram alterações, os quais foram testados em conjunto. Uma vez que uma ou mais mudanças são desen-volvidas, testadas e empacotadas para implementação, o processo de Gerenciamento de Liberação é responsável por introduzi-las na infra-estrutura de TI e gerenciar as atividades relacionadas com tal liberação.

O processo de Gerenciamento de Liberação também contribui para aumentar a efici-ência da introdução de mudanças no ambiente de infra-estrutura de TI, combinando-as em uma única liberação e realizando a implementação das mesmas em conjunto.

1.24.6 Gerenciamento do Nível de Serviço

O processo de Gerenciamento do Nível de Serviço é a base para o gerenciamento dos serviços que a área de TI aprovisiona para a organização. Sua responsabilidade é assegurar que os serviços de TI, dentro dos níveis de serviços acordados, serão entregues quando e onde as áreas usuárias o definirem. Tal processo depende de todos os demais processos

Page 253: Analista de Sistema Operacional

71Capítulo 1 • Introdução

de entrega de serviços (Service Delivery), e seu gerente geralmente é o próprio gerente da área de TI, haja vista a sua importância para a imagem da área de TI perante toda a organização.

O processo Gerenciamento do Nível de Serviço pode ser divido nas seguintes subpro-cessos:

• Revisão dos serviços disponibilizados.

• Negociação com os clientes.

• Revisão dos contratos de serviços com fornecedores externos.

• Desenvolvimento e monitoração dos acordos de nível de serviço.

• Implementação das políticas e dos processos de melhoria contínua.

• Estabelecimento de prioridades.

• Planejamento do crescimento dos serviços.

• Definição do custo dos serviços em conjunto com o gerenciamento financeiro e da forma de ressarcimento destes custos.

1.24.7 Gerenciamento da Capacidade

O processo de Gerenciamento da Capacidade é responsável pela disponibilização no tempo certo, no volume adequado e no custo apropriado dos recursos de infra-estrutura de TI necessários ao atendimento das demandas do negócio em termos de serviços de TI, garantindo que os recursos disponíveis sejam utilizados da forma mais eficiente possível. Para atingir seus objetivos, é imprescindível a identificação dos serviços de TI que serão requeridos pelas áreas de negócio da organização, a definição de qual infra-estrutura de TI e o nível de contingência serão necessários, além de calcular o custo desta infra-estrutura.

O processo Gerenciamento de Capacidade pode ser divido nas seguintes subprocessos:

• Monitoração do desempenho.

• Monitoração da carga de trabalho/demanda.

• Dimensionamento da aplicação.

• Projeção de recursos.

• Projeção da demanda.

• Estabelecimento de modelos.

Page 254: Analista de Sistema Operacional

72 Gerenciamento de Serviços de TI na Prática

1.24.8 Gerenciamento da Disponibilidade

O Gerenciamento da Disponibilidade é o processo da ITIL que visa determinar os níveis de disponibilidade dos diversos serviços de TI a partir dos requerimentos do negócio. Uma vez definidos os níveis de disponibilidade, estes devem ser discutidos com as áreas-cliente, passando o resultado a constar dos acordos de nível de serviço assinados. A disponibilidade é, em geral, calculada com base em um modelo que considera a disponibilidade média e os impactos decorrentes dos pontos de falha mapeados com a utilização da técnica Fault Tree Analysis (FTA).

1.24.9 Gerenciamento da Continuidade dos Serviços de TI

O processo de Gerenciamento da Continuidade dos Serviços de TI é o responsável pela validação dos planos de contingência e recuperação dos serviços de TI após a ocorrência de acidentes. Ele não trata apenas de medidas reativas, mas também de medidas proativas decorrentes de ações de mitigação dos riscos de ocorrência de um desastre em primeira instância.

O Plano de Continuidade do Negócio é desenvolvido atualmente não apenas para garantir a recuperação e a disponibilização dos serviços de TI, mas também com uma visão de recuperação do processo de negócio, utilizando uma visão fim-a-fim, de modo que a organização volte o mais rápido possível a operar e a atender seus clientes finais, após a ocorrência de um desastre.

1.24.10 Gerenciamento Financeiro

O processo de Gerenciamento Financeiro é aquele cujo objetivo é determinar o verdadeiro custo de todos os serviços de TI e demonstrá-lo de maneira que a organização possa en-tendê-lo e utilizá-lo para o processo de tomada de decisão. Posteriormente, é responsável pelo estabelecimento dos mecanismos que viabilizem a cobrança do custo dos serviços de TI de seus respectivos clientes.

1.25 O que não é ITIL

A atenção crescente dada às melhores práticas reunidas na ITIL é vista pela comunidade de Gerenciamento de TI como uma possibilidade de ajuda às áreas de TI a conseguirem formar melhores Acordos de Nível de Serviço (ANS) e a respeitarem de forma mais eficiente esses ANSs. Porém, o crescimento de algo bom é sempre acompanhado pelo inevitável lado ruim, representado pelo entendimento limitado ou errôneo do que venha a ser a ITIL, o que representa um perigo. Para compreender o que é a ITIL necessário se faz olhar para o lado realista, ver o que é e o que oferece, assim como para aquilo que não corresponde à verdade.

Page 255: Analista de Sistema Operacional

73Capítulo 1 • Introdução

A ITIL tem-se mantido relevante e aberta à evolução realizando sabiamente uma dis-tinção entre estabelecer a pedra básica dos processos de TI e ditar como devem ser tais processos. Contudo, já está ocorrendo confusão entre os diferentes fornecedores de serviços de TI, relativamente a esta distinção – prevendo todo o tipo de serviços de consultoria e produtos de software que afirmam ser ITIL-compliance, mas que deixam para os seus compradores perceber o que essas afirmações representam e fazem.

Em termos de consulta e planejamento, as linhas-mestres encontradas na ITIL são bastante úteis, e a prática da consulta pode ajudar às áreas de TI a evoluírem para um Gerenciamento de Serviços de TI mais efetivo e econômico, segundo já foi referido.

Mas é imprescindível ter atenção, pois não se pode pensar que a ITIL consegue fornecer por si só a fórmula mágica para o sucesso. Para se alcançar o sucesso no Gerenciamento de Serviços de TI, de acordo com a metodologia IT Flex®, são necessários quatro aspectos básicos: serviços, processos, pessoas e tecnologia. A ITIL apenas foca os processos, tratando os outros, na maior parte das vezes de forma indireta.

A relação entre tecnologia e processos é bastante complexa, e a ITIL é cuidadosa ao distinguir pontos de ligação sem ficar verdadeiramente envolvida em problemas de tec-nologia ou de arquitetura.

É certamente importante ler o conjunto de livros da ITIL como ponto de partida para determinar que categorias de processos são necessárias para uma aproximação bem-suce-dida do Gerenciamento de Serviços de TI à estratégia de negócio da organização e, talvez até mais importante, como essas categorias se inter-relacionam.

Mas a ITIL deve ser vista como ponto de partida, e não de chegada. Será mais eficaz nas mãos de uma liderança capaz de pensar criativamente sobre suas organizações, culturas e necessidades do negócio, mas também capaz de ser proativa e inovadora na escolha das tecnologias empregadas.

A estratégia ganhadora é aquela que olha para os quatro aspectos básicos (serviços, processos, pessoas e tecnologia) com uma mente aberta e capacidade de construir todos os aspectos a partir de forças.

É importante reter as seguintes conclusões, neste momento:

• A ITIL não é uma metodologia para implementar processos de Gerenciamento de Serviços de TI, mas um conjunto de melhores práticas flexível que permite adapta-ções para ir ao encontro das necessidades específicas.

• A ITIL não contém mapas detalhados dos processos, ela fornece os fundamentos e as informações para a construção e a melhoria dos processos da área de TI.

• A ITIL não fornece instruções de trabalho, só a área de TI sabe como se trabalha.

Page 256: Analista de Sistema Operacional

74 Gerenciamento de Serviços de TI na Prática

1.26 Adoção da ITIL

Na grande maioria das organizações, é comum a inexistência de um ponto único de contato para a requisição de suporte sobre as questões que interferem com disponibi-lidade e o funcionamento normal dos serviços de TI por parte dos usuários. Apesar de existirem muitas maneiras e produtos que permitam a centralização em um único ponto de todos os incidentes com os serviços de TI de uma organização, a satisfação e o esforço de manutenção associados acabam – com o passar do tempo – por desiludir os gerentes, clientes e usuários.

O grande incentivador desta situação é a pouca comunicação e a baixa cooperação entre as áreas de uma organização, principalmente entre as subáreas de TI, resultando em incidentes que levam à degradação do tempo de resposta dos serviços de TI ou mesmo à sua total indisponibilidade, resultando na baixa percepção da qualidade dos serviços de TI e no desgaste da imagem da área de TI perante os clientes.

Muitas áreas de TI, por tentarem acompanhar a inovação para responder às exigências do negócio, tornam-se incapazes de manter atualizados os procedimentos já estabelecidos, e passam muito tempo em intervenções reativas, resolvendo repetidamente incidentes e problemas, em vez de eliminá-los.

Muitas vezes, existe demasiada dependência de pessoas-chave pelo fato de o conheci-mento que elas detêm não estar documentado. Um problema adicional resulta do fato de muitas pessoas da área de TI precisarem de orientação para as necessidades e questões dos clientes, ou seja, estarem focadas no cliente.

Outro grande impacto vem geralmente da inexistência de cultura de celebração de acordos de nível de serviço com os clientes dos serviços de TI. Desse modo, as expectativas do cliente não são claramente compreendidas nem a forma do fornecimento dos serviços de TI é clara para o cliente. Uma razão para isto é que a informação necessária para o gerenciamento dos serviços de TI entregues aos clientes não está disponível – as decisões baseiam-se na sensibilidade em vez de serem fundamentadas. O valor que se extrai do investimento não pode ser julgado sem que exista um bom conhecimento dos custos, in-cluindo o de alterações. Um conhecimento dos custos incorridos na prestação dos serviços de TI também fornece uma base sólida para decisões no departamento da TI.

As melhores práticas reunidas na ITIL descrevem uma nova abordagem para esta problemática do suporte aos serviços de TI, em que os diferentes pontos de contato dos usuários com a área de TI podem ser substituídos pela Central de Serviços, onde os acordos de nível de serviço têm condições de serem gerenciados com claro conhecimento dos seus objetivos e âmbito, tanto para o cliente quanto para a própria área de TI. A ITIL também aborda o gerenciamento financeiro das diversas fontes de custos existentes nos processos de gerenciamento de serviços, de modo a que os serviços fornecidos estejam alinhados com as necessidades e exigências do negócio.

Page 257: Analista de Sistema Operacional

75Capítulo 1 • Introdução

Ao adotar as melhores práticas reunidas na ITIL, a área de TI deve investir todo o empenho que for necessário para que elas sejam implementadas e cheguem a trazer o retorno esperado. Na Tabela 1.6, apresentam-se os prazos para a implementação dos di-versos processos da ITIL, apurados de implementações reais. Tal empenho, conforme já foi visto, envolve harmonizar a interação entre pessoas, processos e tecnologia, de forma a assegurar o Gerenciamento dos Serviços de TI, conforme descrito a seguir:

• Pessoas – Aqui são considerados todos aqueles envolvidos em um ou mais proces-sos de gerenciamento da ITIL. O empenho de cada um é imperioso, e, para tanto, a comunicação, a capacitação, o treinamento e as definições claras dos papéis e das responsabilidades são essenciais para atingir e manter o fornecimento de serviços de TI alinhados com a estratégia de negócio da organização.

• Processos – Conforme descrito na ITIL, os processos de gerenciamento constituem os seus pilares e oferecem uma forma organizada para implementação, a qual pode ser adaptada às necessidades particulares de cada organização.

• Tecnologia – Apesar de a ITIL não estar afeta a nenhuma tecnologia ou família de produtos, a sua implementação pode ser mais eficaz se as ferramentas escolhidas usarem a terminologia definida por ela. O número de ferramentas “compatíveis com as melhores práticas reunidas na ITIL” tem crescido de forma rápida e pode ser acompanhada pela consulta à URL http://www.pinkelephant.com/en-US/PinkVe-rify/PinkVerifyToolset.htm, o que indica uma crescente adoção das práticas ITIL em escala mundial.

Tabela 1.6 – Prazo de implementação dos processos da ITIL Fonte: InterProm USA Corporation

Processo ITILPrazo para a implementação

Pequenas e médias organizações

Grandes organizações

Gerenciamento de Incidente 3 a 6 meses 6 a 24 meses

Gerenciamento de Problema 1 a 3 meses 3 a 4 meses

Gerenciamento de Configuração 3 a 4 meses 4 a 12 meses

Gerenciamento de Mudança 1 a 3 meses 3 a 5 meses

Gerenciamento de Liberação 1 mês 1 a 2 meses

Gerenciamento de Disponibilidade 3 a 6 meses 6 a 9 meses

Gerenciamento de Capacidade 4 a 6 meses 6 a 12 meses

Gerenciamento Financeiro 4 a 6 meses 6 a 9 meses

Gerenciamento de Continuidade 3 a 6 meses 6 a 12 meses

Gerenciamento de Nível de Serviço 2 a 4 meses 4 a 6 meses

Page 258: Analista de Sistema Operacional

76 Gerenciamento de Serviços de TI na Prática

1.27 Como a ITIL adiciona valor aos serviços de TI

O grau em que o serviço de TI está alinhado com o as necessidades da organização pode ser avaliado pela utilização de indicadores de desempenho calculados a partir de medidas obtidas dos próprios processos de TI, quer sejam operados interna ou externamente.

Muitas áreas de TI geram relatórios com indicadores de desempenho, mas pouco focados nas necessidades de informação sobre o desempenho de TI do ponto de vista do negócio. No decorrer da apresentação dos diversos processos definidos pelas melhores práticas reunidas na ITIL, ao longo deste livro, serão apresentadas sugestões de indicadores de desempenho, de modo a permitir a montagem de um painel de monitoração (dashboard) baseado nas metodologias Balanced Scorecard (BSC) e Strategic Activity System (SAS®) para a avaliação do desempenho de TI no Gerenciamento dos Serviços de TI sob o ponto de vista do negócio.

A fim de garantir a tradução das necessidades da organização em termos de requeri-mentos de serviços de TI, a ITIL propõe o processo de gerenciamento do nível de serviço (Service Level Management – SLM). Tal processo viabiliza a definição de valores-padrão para as diferentes variáveis de desempenho consideradas importantes para um determi-nado serviço de TI, celebrando um acordo de nível de serviço (Service Level Agreement – SLA) entre o cliente (áreas de negócio) e a área de TI. Ao realizar esta tarefa, define-se a importância e a contribuição de cada serviço de TI para o negócio, possibilitando que esta área gerencie e demonstre o valor de sua contribuição na execução da estratégia da organização.

Resumindo, serviços de TI que verdadeiramente agregam valor são aqueles alinhados com os requerimentos do negócio e com a estratégia de negócio da organização.

1.28 Benefícios da implementação da ITIL

Para alcançar os benefícios propalados da adoção das melhores práticas reunidas na ITIL, é necessário que a organização que as adota já tenha reconhecido a sua importância e esteja seriamente comprometida com a sua implementação, envolvendo toda a sua equipe, tanto da área de TI quanto nos setores de negócio. Com a obtenção do comprometimento de todos os envolvidos, os benefícios serão:

• Melhoria na qualidade dos serviços de TI, tornando-os mais confiáveis para o su-porte à execução da estratégia de negócio.

• Alinhamento do plano de continuidade dos serviços de TI aos interesses da orga-nização e maior probabilidade de sucesso na sua execução.

• Clareza na visão da atual capacidade da área de Tecnologia da Informação em entregar e suportar os serviços de TI demandados pela organização.

Page 259: Analista de Sistema Operacional

77Capítulo 1 • Introdução

• Melhor informação sobre os atuais serviços de TI, possibilitando priorizar as alte-rações e melhorias necessárias.

• Aumento da flexibilidade para o negócio pela melhoria no conhecimento da área de TI sobre as reais necessidades do negócio.

• Maior motivação dos integrantes da equipe de TI derivada da melhoria na satisfação no trabalho, obtida por um conhecimento melhor da capacidade disponível e mais elevada gestão das expectativas, tanto de TI quanto dos clientes e usuários.

• Melhoria na satisfação dos clientes, pois a área de TI passa a conhecer e fornecer o que eles esperam.

• Aumento da flexibilidade e da capacidade de adaptação dos serviços de TI às mu-danças impostas pela estratégia de negócio da organização.

• Diminuição nos prazos de atendimento de incidentes, solução de problemas e exe-cução de mudanças, associadas ao aumento da taxa de sucesso em tais processos.

• Melhor compreensão e controle dos custos, possibilitando o acompanhamento dos investimentos e a conciliação das despesas operacionais, bem como a cobrança dos serviços de TI prestados aos clientes.

• Melhoria da imagem da área de TI pelo incremento da qualidade dos serviços de Tecnologia da Informação, atraindo novos clientes e encorajando o aumento da demanda de serviços de TI por parte da clientela atual.

• Priorização das ações de melhoria nos serviços de TI, de acordo com as necessidades de atendimento dos níveis de serviços acordados com os clientes para os serviços de TI.

Desta relação de benefícios, alguns poderão ser dependentes ou ter maior expressão de acordo com o contexto da organização e do tipo de indústria em que ela atua, ou seja, os benefícios da ITIL diferem de uma organização para outra. Pela mesma razão, outros benefícios que não aparecem no rol anterior poderão ser obtidos. O fundamental é que a adoção da ITIL permitirá a adoção de uma cultura de melhoria contínua da qualida-de dos serviços prestados pela área de TI, que, no mínimo, garantirá a manutenção dos ganhos já obtidos.

1.29 Resultados

Os resultados advindos da adoção da ITIL são muitos e, em inúmeros casos, significativos. Organizações que já adotaram a ITIL alcançaram resultados em termos de redução de custos operacionais, aumento da eficiência, diminuição do time-to-market para produtos e serviços apoiados por TI, elevação da produtividade da equipe de TI, incremento na efeti-

Page 260: Analista de Sistema Operacional

78 Gerenciamento de Serviços de TI na Prática

vidade para o negócio da área, entre outros. Recentemente, algumas organizações tornaram públicos os resultados alcançados com a implementação das recomendações da ITIL:

• Caterpillar – Obteve um aumento de 60% para mais de 90% no índice de aten-dimento de incidentes realizado nos acordos de nível de serviço firmados com as unidades de negócio da organização, após 18 meses da implementação.

• Corte de Justiça de Ontário – Implementou e ativou um Service Desk Virtual, reduzindo os custos com suporte técnico em 40%, após dois anos e meio da im-plementação.

• Procter & Gamble – Depois de três anos da implementação, obteve uma redução entre 6 e 8% nos custos operacionais da infra-estrutura de TI e redução entre 15 e 20% do pessoal alocado. No caso específico do Service Desk, foi obtida uma redução de 10% no volume total de chamadas recebidas.

Segundo a organização denominada Quint Wellington Redwood14, os benefícios da adoção da ITIL passam a ser obtidos em até 90 dias, destacando-se a redução do tempo de resolução das incidentes e dos problemas, além da diminuição da quantidade de erros que podem levar a ganhos superiores a 30% em termos de tempo despendido pela equipe da área de TI, assim como a redução do time-to-market, que pode levar a ganhos de até 50% na capacidade de execução de mudanças e projetos.

A Tabela 1.7 apresenta os ganhos obtidos em projetos já realizados de implementação das melhores práticas reunidas na ITIL.

Tabela 1.7 – Resultados de projetos de implementação da ITIL

Variável de desempenho Resultado obtido

Disponibilidade dos Sistemas Incremento de 10% na disponibilidade dos sistemas de TI

Custo de Propriedade Redução de 10% no custo total de propriedade

Capacidade de Processamento Redução de 15% da capacidade disponível

Prazo de Mudança Redução de 25% no tempo necessário para a conclusão das mudanças

Prazo de Reparo Redução de 80% no tempo para a realização de reparos decorrentes de incidentes

Volume de Mudanças Redução de 50% da quantidade de mudanças urgentes e dispendiosas

Volume de Incidentes Redução de 30% na quantidade de incidentes

14 Acesso na Internet pela URL: http://www.quintgroup.com

Page 261: Analista de Sistema Operacional

Este cenário enfoca a função de virtualização do Windows Server® “Longhorn” que permite a organizações de TI reduzir custos e criar um centro de dados ágil e dinâmico.

A função de virtualização oferece um paradigma inteiramente novo de implantação e licenciamento para que permitir múltiplas instâncias de sistema operacional – tanto da Microsoft como potencialmente de outros fabricantes – sejam executados em uma infra-estrutura virtual separada do hardware por uma tecnologia de virtualização baseada em um monitor fino.

Conforme examinarmos este cenário, será importante manter o foco não apenas no que o cenário oferece, mas também naquilo que possibilita – que é possivelmente todas as outras funções de servidor do Windows Server “Longhorn” e potencialmente Linux e outros sistemas operacionais.

Proposta de Valor do Cenário

A função de virtualização possibilita que organizações criem um centro de dados ágil e dinâmico e reduzam custos. As principais propostas de valor que a virtualização de servidor permitem são essas:

• Consolidação de servidor: Possibilitar que os clientes reduzam a quantidade total e o custo de propriedade de servidor minimizando a utilização do hardware, consolidando cargas de trabalho e reduzindo os custos de gerenciamento.

• Ambientes de desenvolvimento e teste. Criar um ambiente mais flexível e fácil de gerenciar que maximize o hardware de teste, reduza custos, melhore o gerenciamento do ciclo de vida e melhore a cobertura dos testes.

• Gerenciamento de continuidade de negócios. Eliminar o impacto de tempos de inatividade programados e não programados e permitir capacidades de recuperação de desastres com recursos como a Migração ao Vivo e clustering de host.

• Centro de dados dinâmico. Utilizar os benefícios da virtualização para criar uma infra-estrutura mais ágil combinada com novos recursos de gerenciamento para permitir a você mover máquinas virtuais sem causar impacto sobre os usuários.

Requisitos Especiais de Hardware

A função de virtualização requer o seguinte:

• Processadores Intel VT ou AMD-V ativados

Virtualização

Page 262: Analista de Sistema Operacional

2.02 Virtualização do Windows Server

A virtualização é uma tecnologia chave de capacitação que pode ser utilizada para alcançar benefícios comerciais. A tecnologia de virtualização permite que os clientes executem vários sistemas operacionais de maneira concorrente em um único servidor físico, em que cada um dos sistemas operacionais é executado como um computador independente.

Hoje há mais pressão que nunca sobre o TI com orçamentos reduzidos, tecnologias que mudam rapidamente e questões crescentes de segurança. Conforme as empresas crescem, suas infra-estruturas de TI crescem com elas. Mas, freqüentemente, o ritmo desse crescimento é irregular, impulsionado tanto pelas condições sob as quais a empresa opera quanto pelo modelo a que aspira. O TI está sendo cada vez mais visto como um gerador-chave de valor para a maioria das organizações, e o foco do TI é mudar de meramente manter a empresa em funcionamento para ser um mecanismo para produzir reatividade e agilidade por toda a organização.

Produzir agilidade pelo TI, reduzir custos e gerenciar complexidade precisam todos acontecer de uma forma integrada. A Iniciativa de Sistemas Dinâmicos da Microsoft (DSI - Dynamic Systems Initiative) utiliza a virtualização como um pilar principal para tratar dessas preocupações comerciais, e se une estreitamente com a adição de informações às aplicações e na camada de gerenciamento para permitir a visão de sistemas dinâmicos gerenciados automaticamente em todo o ciclo de vida e por todas as funções dentro da organização. A virtualização como tecnologia tem a capacidade de tratar de algumas dessas preocupações e necessidades comerciais como partes da estratégia geral de TI.

Hoje, O Microsoft® Virtual Server 2005 R2 hospedado no sistema operacional Windows Server 2003 proporciona os recursos necessários para cumprir tarefas que poupam tempo e custo através da tecnologia de virtualização em um ambiente de computação "enterpise-ready" com níveis avançados de escalabilidade, gerenciamento e disponibilidade. A abordagem da Microsoft para integrar os recursos de gerenciamento com a família de produtos System Center existente permite aos clientes gerenciar suas infra-estruturas física e virtual d uma forma integrada e facilita a adoção da tecnologia.

“A estratégia de virtualização da Microsoft contrasta com as alternativas atuais

para gerenciamento de máquina virtual, que tendem a ser complexas, caras e exigir

habilidades especializadas. Vemos a virtualização como uma tecnologia-chave para

ajudar os clientes a alcançarem sistemas dinâmicos auto-gerenciados. Ao longo das

camadas da plataforma, sistema operacional, aplicações e gerenciamento, estamos

proporcionando funcionalidade e recursos que permitem a nossos clientes reduzir

significativamente custos operacionais, aumentar a utilização do servidor e alcançar

um ROI melhor através de soluções de virtualização de recursos plenos.”

Bob Muglia, Vice-Presidente Sênior, Negócios de Servidor e Ferramentas,

Microsoft

A Virtualização do Windows Server, como parte do Windows Server “Longhorn,” dá um grande passo à frente na aplicação de algumas das avançadas capacidades da virtualização e em proporcionar aos clientes uma plataforma de virtualização escalonável, segura e altamente disponível. Conforme as tecnologias de plataforma avançam, é importante assegurar que o gerenciamento geral continue simplificado. O Gerenciador de Máquina Virtual do System Center Microsoft — a aplicação de gerenciamento para centro de dados virtualizado oferece uma solução de gerenciamento unificada e integrada como

Page 263: Analista de Sistema Operacional

20

parte da família System Center e ajuda a baixar os custos na à medida que o ambiente de TI se torna mais ágil.

Benefícios da Virtualização

Organizações de TI hoje estão sob uma pressão incrível para fornecer mais valor a seus clientes comerciais – e tipicamente com pouco ou nenhum aumento no orçamento. Otimizar o uso de ativos físicos de TI se torna imperativo à medida que os centros de dados atingem sua capacidade de potência e espaço. A Microsoft reconhece que o problema se intensifica para empresas cujos servidores trabalham com utilização muito baixa. Taxas de utilização de servidor de menos de 5 por cento não são incomuns, e as taxas de utilização de muitos clientes caem dentro da faixa de 10- a 15 por cento. Muitos desses desafios, compartilhados entre administradores de servidor e desenvolvedores, podem ser tratados com a ajuda das soluções de virtualização da Microsoft.

A tecnologia de virtualização de máquina é usada para consolidar várias máquinas físicas em uma única máquina física. A virtualização também pode ser usada para re-hospedar ambientes de legado, especialmente conforme o hardware de geração mais antiga se torna mais difícil e dispendioso para manter. E como o software é separado do hardware, a virtualização é uma boa solução para ambientes de recuperação de desastres, também.

Como uma parte essencial de qualquer estratégia de consolidação de servidor, as soluções de virtualização da Microsoft aumentam a utilização do hardware e permitem que as organizações configurem e implantem rapidamente novos servidores com os seguintes importantes benefícios:

• Uso eficiente de recursos de hardware. O isolamento e gerenciamento de recursos de máquina virtual possibilitam a coexistência de várias cargas de trabalho em menos servidores, permitindo que as organizações façam um uso mais eficiente de seus recursos de hardware. A Virtualização do Windows Server, parte do Windows Server “Longhorn” e do Virtual Server 2005 R2 com Windows Server 2003, proporciona a maior interoperabilidade com infra-estruturas existentes de armazenamento, rede e segurança. Com avanços em hardware de servidor com tecnologia de 64 bits, sistemas multiprocessados e de múltiplos núcleos, a virtualização oferece uma maneira fácil de otimizar a utilização de hardware.

• Produtividade e reatividade administrativas melhoradas. A Virtualização do Windows Server possibilita a organizações de TI melhorar sua produtividade administrativa e implantar rapidamente novos servidores para tratar das necessidades corporativas sempre em transformação. A integração fácil com ferramentas de gerenciamento de servidor existentes, como o System Center Operations Manager e ferramentas sofisticadas como o Gerenciador de Máquina Virtual do System Center (SCVMM), facilita o gerenciamento de máquinas virtuais Windows. A capacidade de consolidar cargas de trabalho em um ambiente de hardware não virtual e um framework físico e virtual integrado de gerenciamento de TI permite que administradores reduzam os custos operacionais e criem centros de dados mais ágeis.

• Solução de virtualização de servidor bem suportada. O Virtual Server 2005 R2 é extensivamente testado e suportado pela Microsoft em conjunto com seus sistemas operacionais e aplicações de servidor. Por isso o Virtual Server 2005 R2 é uma solução de virtualização bem suportada tanto dentro da Microsoft como na comunidade de ISVs mais ampla. Com a Virtualização do Windows Server como

Page 264: Analista de Sistema Operacional

21

um componente integrante do Windows Server “Longhorn” e o Gerenciador de Máquina Virtual como parte da família System Center, você pode ter certeza de que as futuras soluções de virtualização da Microsoft também serão extensivamente testadas e bem suportadas. O uso de um formato de disco rígido virtual comum (VHD) assegura a proteção do investimento para todas as máquinas virtuais criadas para o Servidor Virtual com um caminho transparente de migração para a Virtualização do Windows Server.

• Um produto-chave para a Iniciativa de Sistemas Dinâmicos da Microsoft.

Como parte da DSI, o esforço da Microsoft abrangendo toda a indústria para simplificar e automatizar dramaticamente como as empresas projetam, implantam e operam sistemas de TI para permitir sistemas dinâmicos auto-gerenciados, a Microsoft está oferecendo às empresas ferramentas para ajudá-las a utilizar de maneira mais flexível seus recursos de hardware. O Virtual Server 2005 R2, a Virtualização do Windows Server e o Gerenciador de Máquina Virtual são exemplos importantes de como a Microsoft está continuando a fornecer tecnologia que resulta em melhor utilização de hardware de servidor e proporciona um aprovisionamento mais flexível de recursos e centros de dados.

Roadmap da Virtualização da Microsoft

O roadmap da Virtualização da Microsoft combina o seguinte:

• Uma visão de longo prazo que mostra como os clientes podem reduzir drasticamente a complexidade da infra-estrutura de TI como parte da DSI global.

• Um cronograma de produto sólido que oferece soluções atuais e de curto prazo, permitindo que os clientes tomem uma série de passos práticos de acordo com a visão de longo prazo.

A Microsoft está fornecendo soluções de ferramentas de desenvolvimento de aplicações, aplicações de servidor, sistemas operacionais e gerenciamento que proporcionam melhorias imediatas para tratar da complexidade no ambiente de TI dos clientes. Como parte das soluções de virtualização, os clientes verão melhorias na oferta atual de produtos para o Virtual Server 2005 R2; novos produtos avançados como o Gerenciador de Máquina Virtual do System Center que tratarão de importantes desafios de gerenciamento; e a Virtualização do Windows Server como parte do Windows Server “Longhorn” que fornecerá uma plataforma melhorada de virtualização com escalabilidade, desempenho e confiabilidade aumentados.

Com a capacidade de hardware crescendo e recursos mais robustos de plataforma de virtualização e gerenciamento, mais clientes podem se beneficiar dos recursos de consolidação, gerenciamento mais fácil e automação. A virtualização é a principal tecnologia para reduzir o custo e complexidade do gerenciamento de TI, e a Microsoft comprometeu recursos significativos para tornar a virtualização mais amplamente acessível para os clientes.

As próximas seções enfocarão os principais produtos de virtualização, tanto no nível da plataforma como no de gerenciamento.

Virtual Server 2005 R2

O Microsoft Virtual Server 2005 R2 é á tecnologia de virtualização de servidor mais eficaz em termos de custo projetada para a plataforma Windows Server System™. Como parte essencial de qualquer estratégia de consolidação de servidor, o Virtual Server aumenta a

Page 265: Analista de Sistema Operacional

utilização de hardware e permite que as organizações configurem e implantem novos servidores rapidamente.

Cenários de Uso

O Virtual Server 2005 R2 oferece eficiência de hardware melhorada oferecendo uma ótima solução para isolamento e gerenciamento de recursos, o que possibilita a coexistência de múltiplas cargas de trabalho em menos servidores. O Virtual Server pode ser usado para melhorar a eficiência operacional na consolidação de infra-estrutura, cargas de trabalho de servidor de aplicações e em escritórios remotos, consolidando e re-hospedando aplicações de legado, automatizando e consolidando ambientes de testes e de desenvolvimento de software, e reduzindo o impacto de desastres.

• Consolide infra-estrutura, cargas de trabalho de servidor de aplicações e em

escritórios remotos. O Virtual Server permite a consolidação de cargas de trabalho para ambientes de serviço de infra-estrutura, de escritórios remotos, e recuperação de desastres, resultando em menos sistemas físicos para memória de hardware reduzida. O Virtual Server 2005 R2 é ideal para consolidação de servidor tanto no centro de dados como no escritório remoto, permitindo às organizações fazerem um uso mais eficiente de seus recursos de hardware. Ele permite que as organizações de TI aumentem sua produtividade administrativa e implantem rapidamente novos servidores para tratar de necessidades comerciais e aumenta as taxas de utilização de hardware para uma infra-estrutura de TI otimizada.

• Consolide e automatize seu ambiente de teste e desenvolvimento de

software. Clientes em todos os segmentos procuram maneiras de diminuir os custos e acelerar instalações e atualizações de aplicações e infra-estrutura, ao mesmo tempo em que fornecem um nível abrangente de garantia de qualidade. O Virtual Server permite que você consolide sua farm de servidores de testes e desenvolvimento e automatize o aprovisionamento de máquinas virtuais, melhorando a utilização de hardware e a flexibilidade operacional. Para desenvolvedores, o Virtual Server permite uma fácil implantação e testes de uma aplicação de servidor distribuída usando múltiplas máquinas virtuais em um servidor físico.

• Re-hospede aplicações de legado. O Virtual Server permite a migração de sistemas operacionais de legado (Windows NT® 4.0 Server e Windows® 2000 Server) e suas aplicações personalizadas associadas de hardwares mais antigos para servidores novos executando o Windows Server 2003. O Virtual Server 2005 R2 oferece o melhor dos dois mundos: compatibilidade de aplicação com ambientes de legado, ao mesmo tempo em que tira proveito da confiabilidade, gerenciamento e recursos de segurança do Windows Server 2003 sendo executado no hardware mais recente. O Virtual Server 2005 R2 oferece essa capacidade permitindo que os clientes executem aplicações de legado em seu ambiente nativo de software em máquinas virtuais, sem reescrever a lógica da aplicação, reconfigurar redes ou treinar novamente os usuários finais. Isso dá aos clientes tempo para primeiro atualizar sistemas mais antigos da infra-estrutura, depois para atualizar ou reescrever aplicações fora de serviço em um cronograma que atenda melhor suas necessidades comerciais. O Virtual Server 2005 R2 possibilita uma melhor escolha do cliente para migração de aplicações de legado com excepcional compatibilidade.

• Soluções de recuperação de desastre. O Virtual Server 2005 R2 pode ser usado como parte de um plano de recuperação de desastres que requeira portabilidade

Page 266: Analista de Sistema Operacional

23

Virtual Server 2005 R2: Administration Website

e flexibilidade de aplicação ao longo de plataformas de hardware. Consolidar servidores físicos em poucas máquinas físicas executando máquinas virtuais diminui o número de ativos físicos que deve estar disponíveis em um local de recuperação de desastre. No caso de recuperação, máquinas virtuais podem ser hospedadas em qualquer local, em máquinas host diferentes daquelas afetadas pelo desastre, acelerando os tempos d recuperação e maximizando a flexibilidade da organização.

Principais Recursos

A virtualização facilita ampla compatibilidade de dispositivos e suporte completo para ambientes de servidor Windows.

• Isolamento de máquina virtual. O isolamento de máquina virtual garante que se uma máquina virtual cair ou travar, não tenha impacto sobre nenhuma outra máquina virtual ou sobre o sistema host. A compatibilidade máxima da aplicação é alcançada através do isolamento. Isso permite que os clientes potencializem ainda mais suas infra-estruturas existentes de armazenamento, rede e segurança.

• Ampla compatibilidade de dispositivos. O Virtual Server é executado no Windows Server 2003, que suporta a maioria dos dispositivos do Catálogo do Windows Server, oferecendo compatibilidade com uma ampla gama de hardwares de sistemas de host.

• VMM multithread. O Monitor de Máquina Virtual do Virtual Server fornece a infra-estrutura de software para criar, gerenciar e interagir com máquinas virtuais em hardware multiprocessado.

• Ampla

compatibilidade com

sistema operacional

x86 guest. O Virtual Server pode executar todos os principais sistemas operacionais x86 no ambiente guest da máquina virtual. A Microsoft também suportará distribuições específicas de Linux sendo executadas no ambiente da máquina virtual.

• Clustering iSCSI. Cenários flexíveis de clustering proporcionam alta disponibilidade para ambientes críticos ao mesmo tempo em que melhoram os processos de atualização e manutenção de hardware. O clustering de iSCSI entre hosts físicos do Virtual Server 2005 R2 oferece um meio eficaz em termos de custo de aumentar a disponibilidade do servidor.

• Suporte a x64. O Virtual Server 2005 R2 é executado nos seguintes sistemas operacionais host de 64 bits: Windows Server 2003 Standard x64 Edition, Windows

Page 267: Analista de Sistema Operacional

24

Server 2003 Enterprise x64 Edition Windows XP Professional x64 Edition, proporcionando desempenho e maior espaço de memória.

• API de COM abrangente. Isso permite completo controle em script de ambientes de máquina virtual. O Virtual Server suporta uma Interface de Programação de Aplicações (API) de Modelo de Objeto Componente (COM) que contém 42 interfaces e centenas de chamadas, permitindo que scripts controlem quase todos os aspectos do produto.

• Discos Rígidos Virtuais (VHDs - Virtual Hard Disks). O Virtual Server encapsula máquinas virtuais e, VHDs portáteis, permitindo uma configuração, versão e implantação flexíveis.

• Boot PXE. Esta placa de rede emulada no Virtual Server 2005 R2 agora suporta boot de Ambiente de Execução Pré-Inicialização (PXE - Pre-Boot Execution Environment). Esse boot de rede permite que os clientes aprovisionem suas máquinas virtuais de todas as maneiras que fazem com os servidores físicos.

• Integração com o Active Directory. As máquinas virtuais no Virtual Server funcionam como se esperaria de uma máquina física, oferecendo integração completa com o Active Directory®. Esse nível de integração permite administração delegada e acesso de convidado seguro e autenticado.

• Microsoft Operations Manager 2005 Management Pack for Virtual Server. Um pacote de gerenciamento desenvolvido especificamente para o Virtual Server possibilita recursos avançados de gerenciamento dentro de máquinas virtuais.

Virtualização do Windows Server

A Virtualização do Windows Server é uma tecnologia baseada em monitor que é parte do Windows Server “Longhorn.” O hypervisor Windows é uma camada fina de software sendo executada diretamente no hardware, que trabalha em conjunto com uma instância otimizada do Windows Server “Longhorn” que permite que múltiplas instâncias do sistema operacional sejam executadas simultaneamente em um servidor físico. Ela utiliza as poderosas melhorias de processadores e oferece aos clientes uma plataforma de virtualização escalonável, confiável, de segurança aprimorada, e altamente disponível.

Cenários de Uso

A Virtualização do Windows Server é integrada como a função de virtualização no Windows Server “Longhorn” e oferece um ambiente virtual mais dinâmico para consolidar cargas de trabalho. Ela fornece uma plataforma de virtualização que permite eficiência operacional aprimorada para consolidação de cargas de trabalho, gerenciamento de continuidade de negócios, automatizar e consolidar ambientes de testes de software, e criar um centro de dados dinâmico.

• Consolidação de servidor de produção. Organizações procuram servidores de produção em seus centros de dados e encontram níveis de utilização geral de hardware entre 5 e 15 por cento da capacidade do servidor. Além disso, limitações físicas como espaço e potência as estão impedindo de expandir seus centros de dados. Consolidar vários servidores de produção com a Virtualização do Windows Server pode ajudar as empresas a se beneficiarem da utilização aumentada do hardware e do custo total de propriedade geral reduzido.

• Gerenciamento de continuidade de negócios. Os administradores de TI estão sempre tentando encontrar maneiras de reduzir ou eliminar o tempo de

Page 268: Analista de Sistema Operacional

25

Windows Server Virtualization: User Interface and multi-proc support

inatividade de seu ambiente. A Virtualização do Windows Server oferecerá recursos para recuperação eficiente de desastres para minimizar o tempo de inatividade. O ambiente de virtualização robusto e flexível criado pela Virtualização do Windows Server minimiza o impacto de tempos de inatividade programados e não programados.

• Teste e desenvolvimento de software. Uma das maiores áreas onde a tecnologia de virtualização continuará sendo relevante é a de teste e desenvolvimento de software para criar ambientes automatizados e consolidados que sejam ágeis o suficiente para acomodar as exigências em constante mudança. A Virtualização do Windows Server ajuda a minimizar o hardware de teste, melhora o gerenciamento de ciclo de vida e melhora a cobertura dos testes.

• Centro de dados dinâmico. O rico conjunto de recursos da Virtualização do Windows Server combinado com os novos recursos de gerenciamento estendidos pelo Gerenciador de Máquina Virtual permite que as organizações criem uma infra-estrutura mais ágil. Os administradores serão capazes de adicionar recursos dinamicamente a máquinas virtuais e movê-las através de máquinas físicas de maneira transparente sem causar impacto nos usuários.

Principais Recursos

Há vários novos recursos na Virtualização do Windows Server que ajudam a criar uma plataforma de virtualização escalonável, segura e altamente disponível como parte do Windows Server “Longhorn.” Os seguintes são alguns dos principais componentes e recursos da Virtualização do Windows Server.

• Monitor Windows. É uma camada finíssima de software que utiliza o suporte a driver e a tecnologia de virtualização assistida por hardware do Windows Server. A base de código mínimo sem nenhum código ou driver de terceiros ajuda a criar uma base mais segura e robusta para soluções de virtualização.

• Gerenciamento dinâmico de recursos. A Virtualização do Windows Server oferece a capacidade de incluir a quente recursos como CPU, memória, redes e armazenamento às máquinas virtuais sem tempo de inatividade. Combinado com os recursos de conexão a quente do Windows Server “Longhorn”, isso permite que os administradores gerenciem seus recursos de hardware sem impacto sobre seus compromissos de SLA.

• Suporte a guest (convidado) de 64 bits. Um novo recurso importante da plataforma de Virtuali-zação do Windows Server é guests de 64 bits. Isso permite que organiza-ções virtualizem mais aplicações que são exigentes em termos de memória e se beneficiem do pool de

Page 269: Analista de Sistema Operacional

26

memória aumentado acessível em um ambiente de 64 bits.

• Suporte a multiprocessador guest (convidado). A Virtualização do Windows Server agora oferece a capacidade de alocar múltiplos recursos de CPU a uma única máquina virtual e permite a virtualização de aplicações multithread. Este recurso, combinado com o suporte a guests de 64 bits, torna a Virtualização do Windows Server uma plataforma escalonável para virtualização.

• Migração em tempo real de máquinas virtuais. A Virtualização do Windows Server proporcionará a capacidade de mover uma máquina virtual de uma máquina física para outra com um mínimo de tempo de inatividade. Esta capacidade, somada ao clustering de host de máquinas físicas, proporciona alta disponibilidade e flexibilidade para se alcançar um centro de dados ágil e dinâmico.

• Nova arquitetura de virtualização de dispositivos. A Virtualização do Windows Server oferece uma nova arquitetura virtualizada de E/S. Isso dá aos clientes um alto desempenho e baixo overhead.

• Manipulação offline de VHD. A Virtualização do Windows Server oferece aos administradores a capacidade de acessar em segurança arquivos dento de um VHD sem ter de criar uma instância de máquina virtual. Isso dá aos administradores acesso granular a VHDs e a capacidade de realizar algumas tarefas de gerenciamento offline.

System Center Virtual Machine Manager

Como parte da família System Center de produtos de gerenciamento, o System Center Virtual Machine Manager facilita o gerenciamento de máquinas virtuais Windows. O System Center Virtual Machine Manager permite uma utilização aumentada de servidor físico permitindo consolidação simples e rápida de infra-estrutura virtual com identificação integrada de candidato de consolidação, P2V rápida, e disposição inteligente da carga de trabalho com base no conhecimento de desempenho e diretivas comerciais definidas pelo usuário. O System Center Virtual Machine Manager possibilita o rápido aprovisionamento de novas máquinas virtuais pelo administrador e usuários finais usando uma ferramenta de aprovisionamento de auto-atendimento. O System Center Virtual Machine Manager é um membro estreitamente integrado da família de produtos de gerenciamento System Center.

Cenários de Uso

O System Center Virtual Machine Manager oferece suporte simples e completo para consolidar hardware em infra-estrutura virtual e otimizar a utilização. Ele também proporciona rápido aprovisionamento de máquinas virtuais a partir de máquinas físicas ou modelos na biblioteca de imagens ou por usuários finais.

• Consolidação de servidor de produção. À medida que as organizações buscam consolidar seus servidores de produção, o System Center Virtual Machine Manager oferece uma maneira de transferir o conhecimento sobre o sistema e o ambiente através do processo de virtualização e ajuda a manter a continuidade do conhecimento. Pela consolidação de vários servidores de produção com o Virtual Server 2005 R2 ou Virtualização do Windows Server, as empresas reduzem o custo total de propriedade geral e ainda mantêm um framework unificado de gerenciamento em seus ambientes físico e virtual.

Page 270: Analista de Sistema Operacional

27

Virtual Machine Manager: Centralized management view

• Aumento da agilidade operacional. Empresas em todos os segmentos procuram maneiras de aumentar a eficiência através de seus ambientes de TI e aumentar a agilidade operacional. O System Center Virtual Machine Manager oferece um mecanismo para permitir funcionalidade como rápido aprovisionamento de servidor, rápida recuperação, e capacidade de migração escalonável para tornar toda a infra-estrutura virtual robusta e fácil de gerenciar.

• Gerenciamento integrado. O System Center Virtual Machine Manager ajuda a criar uma infra-estrutura de gerenciamento centralizado de máquina virtual em múltiplos sistemas host do Virtual Server 2005 R2 e de hosts da Virtualização do Windows Server. Organizações estão adotando a virtualização nas áreas de produção, teste e desenvolvimento, e conforme os recursos de gerenciamento se sofisticam, ela ajuda os administradores a implantar e gerenciar ambientes virtuais e físicos em uma abordagem integrada.

Principais Recursos

O System Center Virtual Machine Manager se concentra em requisitos únicos de máquinas virtuais e é projetado para permitir utilização aumentada de servidor físico, gerenciamento centralizado de infra-estrutura de máquina virtual e rápido aprovisionamento de novas máquinas virtuais. Os seguintes são alguns dos recursos principais do System Center Virtual Machine Manager.

• Identificação de candidato a consolidação. O primeiro passo na migração de um centro de dados físico com um modelo de uma carga de trabalho por servidor é identificar as cargas de trabalho físicas apropriadas para consolidação no hardware virtual. Os fatores de decisão para determinar os candidatos adequados se baseiam em vários fatores, como desempenho histórico, características de pico de carga e padrões de acesso. O System Center Virtual Machine Manager utiliza os dados históricos de desempenho existentes no banco de dados do System Center Operations Manager para listar os candidatos a consolidação em ordem de classificação.

• Disposição inteligente. O ato de designar e ativar uma determinada carga de trabalho virtual em um servidor de host virtual físico é citado como disposição. A disposição está no âmago de maximizar a utilização de ativos físicos. O System Center Virtual Machine Manager traz uma abordagem profunda e holística à disposição e combina o conhecimento de dados históricos de desempenho da

Page 271: Analista de Sistema Operacional

28

carga de trabalho e as informações sobre o sistema de host virtual. Regras comerciais e modelos associados também são utilizadas pelo System Center Virtual Machine Manager para determinar as opções de disposição.

• Aprovisionamento de host. O System Center Virtual Machine Manager identifica os hosts virtuais físicos na empresa através de descoberta integrada com o Active Directory. Isso ajuda as organizações a escalar facilmente o gerenciamento de máquinas e hosts virtuais no centro de dados e escritórios remotos.

• Biblioteca central. O System Center Virtual Machine Manager oferece um repositório central para todos os blocos de construção para uma máquina virtual como VHDs, máquinas virtuais offline, modelos e até mesmo imagens ISO. Cada item da biblioteca possui modelos ou ricos metadados que permitem um gerenciamento mais controlado dos objetos. O modelo é um novo objeto que permite ao administrador criar configurações de máquina virtual aprovadas que servem como um padrão ouro para subseqüentes implantações de máquinas virtuais.

• Aprovisionamento de auto-atendimento. A infra-estrutura virtual é comumente usada em ambientes de teste e desenvolvimento em que há aprovisionamento coerente e desmontagem de máquinas virtuais para fins de teste. Com o System Center Virtual Machine Manager, os administradores podem estender seletivamente os recursos de auto-aprovisionamento a grupos de usuários e ser capazes de definir cotas. A ferramenta de aprovisionamento automático gerencia as máquinas virtuais através de seus ciclos de vida, incluindo desmontagens.

Page 272: Analista de Sistema Operacional

29

2.03 Núcleo do Servidor

No Windows Server “Longhorn,” os administradores agora podem escolher instalar um ambiente mínimo que evita carga extra. Embora esta opção limite as funções que podem ser executadas pelo servidor, pode aumentar a segurança e reduzir o gerenciamento. Esse tipo de instalação é chamado de instalação do Núcleo do Servidor.

Para mais informações sobre o Núcleo do Servidor, consulte a seção 7.05 Núcleo do Servidor na página 242.

Para saber mais, consulte 7.05 Núcleo do Servidor (Server Core) na página 242.

Page 273: Analista de Sistema Operacional

Instrução Normativa GSI/PR nº 1, de 13 de junho de 2008.

Disciplina a Gestão de Segurança da Informação e Comunicações na Administração Pública Federal, direta e indireta, e dá outras providências.

O MINISTRO CHEFE DO GABINETE DE SEGURANÇA INSTITUCIONAL DA PRESIDÊNCIA DA REPÚBLICA, na condição de SECRETÁRIO-EXECUTIVO DO CONSELHO DE DEFESA NACIONAL, no uso de suas atribuições;

CONSIDERANDO:

o disposto no artigo 6º e parágrafo único do art. 16 da Lei nº 10.683, de 28 de maio de 2003;

o disposto no inciso IV do caput e inciso III do §1º do art. 1º e art. 8º do Anexo I do Decreto nº 5.772, de 08 de maio de 2006;

o disposto nos incisos I, VI, VII e XIII do artigo 4º do Decreto nº 3.505, de 13 de junho de 2000;

as informações tratadas no âmbito da Administração Pública Federal, direta e indireta, como ativos valiosos para a eficiente prestação dos serviços públicos;

o interesse do cidadão como beneficiário dos serviços prestados pelos órgãos e entidades da Administração Pública Federal, direta e indireta;

o dever do Estado de proteção das informações pessoais dos cidadãos;

a necessidade de incrementar a segurança das redes e bancos de dados governamentais; e

a necessidade de orientar a condução de políticas de segurança da informação e comunicações já existentes ou a serem implementadas pelos órgãos e entidades da Administração Pública Federal, direta e indireta.

RESOLVE:

Art. 1º Aprovar orientações para Gestão de Segurança da Informação e Comunicações que deverão ser implementadas pelos órgãos e entidades da Administração Pública Federal, direta e indireta.

Art. 2º Para fins desta Instrução Normativa, entende-se por:

I - Política de Segurança da Informação e Comunicações: documento aprovado pela autoridade responsável pelo órgão ou entidade da Administração Pública Federal, direta e indireta, com o objetivo de fornecer diretrizes, critérios e suporte

Page 274: Analista de Sistema Operacional

administrativo suficientes à implementação da segurança da informação e comunicações;

II - Segurança da Informação e Comunicações: ações que objetivam viabilizar e assegurar a disponibilidade, a integridade, a confidencialidade e a autenticidade das informações;

III - disponibilidade: propriedade de que a informação esteja acessível e utilizável sob demanda por uma pessoa física ou determinado sistema, órgão ou entidade;

IV - integridade: propriedade de que a informação não foi modificada ou destruída de maneira não autorizada ou acidental;

V - confidencialidade: propriedade de que a informação não esteja disponível ou revelada a pessoa física, sistema, órgão ou entidade não autorizado e credenciado;

VI - autenticidade: propriedade de que a informação foi produzida, expedida, modificada ou destruída por uma determinada pessoa física, ou por um determinado sistema, órgão ou entidade;

VII - Gestão de Segurança da Informação e Comunicações: ações e métodos que visam à integração das atividades de gestão de riscos, gestão de continuidade do negócio, tratamento de incidentes, tratamento da informação, conformidade, credenciamento, segurança cibernética, segurança física, segurança lógica, segurança orgânica e segurança organizacional aos processos institucionais estratégicos, operacionais e táticos, não se limitando, portanto, à tecnologia da informação e comunicações;

VIII - quebra de segurança: ação ou omissão, intencional ou acidental, que resulta no comprometimento da segurança da informação e das comunicações;

IX - tratamento da informação: recepção, produção, reprodução, utilização, acesso, transporte, transmissão, distribuição, armazenamento, eliminação e controle da informação, inclusive as sigilosas.

Art. 3º Ao Gabinete de Segurança Institucional da Presidência da República - GSI, por intermédio do Departamento de Segurança da Informação e Comunicações - DSIC, compete:

I - planejar e coordenar as atividades de segurança da informação e comunicações na Administração Pública Federal, direta e indireta;

II - estabelecer normas definindo os requisitos metodológicos para implementação da Gestão de Segurança da Informação e Comunicações pelos órgãos e entidades da Administração Pública Federal, direta e indireta;

Page 275: Analista de Sistema Operacional

III - operacionalizar e manter centro de tratamento e resposta a incidentes ocorridos nas redes de computadores da Administração Pública Federal, direta e indireta, denominado CTIR.GOV;

IV - elaborar e implementar programas destinados à conscientização e à capacitação dos recursos humanos em segurança da informação e comunicações;

V - orientar a condução da Política de Segurança da Informação e Comunicações na Administração Pública Federal, direta e indireta;

VI - receber e consolidar os resultados dos trabalhos de auditoria de Gestão de Segurança da Informação e Comunicações da Administração Pública Federal, direta e indireta;

VII - propor programa orçamentário específico para as ações de segurança da informação e comunicações.

Art. 4º Ao Comitê Gestor de Segurança da Informação compete:

I - assessorar o GSI no aperfeiçoamento da Gestão de Segurança da Informação e Comunicações da Administração Pública Federal, direta e indireta;

II - instituir grupos de trabalho para tratar de temas específicos relacionados à segurança da informação e comunicações.

Art. 5º Aos demais órgãos e entidades da Administração Pública Federal, direta e indireta, em seu âmbito de atuação, compete:

I - coordenar as ações de segurança da informação e comunicações; II - aplicar as ações corretivas e disciplinares cabíveis nos casos de quebra de segurança;

III - propor programa orçamentário específico para as ações de segurança da informação e comunicações;

IV - nomear Gestor de Segurança da Informação e Comunicações;

V - instituir e implementar equipe de tratamento e resposta a incidentes em redes computacionais;

VI - instituir Comitê de Segurança da Informação e Comunicações;

VII - aprovar Política de Segurança da Informação e Comunicações e demais normas de segurança da informação e comunicações;

VIII - remeter os resultados consolidados dos trabalhos de auditoria de Gestão de Segurança da Informação e Comunicações para o GSI.

Page 276: Analista de Sistema Operacional

Parágrafo único. Para fins do disposto no caput, deverá ser observado o disposto no inciso II do art. 3º desta Instrução Normativa.

Art. 6º Ao Comitê de Segurança da Informação e Comunicações, de que trata o inciso VI do art. 5º, em seu âmbito de atuação, compete:

I - assessorar na implementação das ações de segurança da informação e comunicações;

II - constituir grupos de trabalho para tratar de temas e propor soluções específicas sobre segurança da informação e comunicações; III - propor alterações na Política de Segurança da Informação e Comunicações; e

IV - propor normas relativas à segurança da informação e comunicações.

Art. 7º Ao Gestor de Segurança da Informação e Comunicações, de que trata o inciso IV do art. 5º, no âmbito de suas atribuições, incumbe:

I - promover cultura de segurança da informação e comunicações;

II - acompanhar as investigações e as avaliações dos danos decorrentes de quebras de segurança;

III - propor recursos necessários às ações de segurança da informação e comunicações;

IV - coordenar o Comitê de Segurança da Informação e Comunicações e a equipe de tratamento e resposta a incidentes em redes computacionais;

V - realizar e acompanhar estudos de novas tecnologias, quanto a possíveis impactos na segurança da informação e comunicações;

VI - manter contato direto com o DSIC para o trato de assuntos relativos à segurança da informação e comunicações;

VII - propor normas relativas à segurança da informação e comunicações.

Art. 8º O cidadão, como principal cliente da Gestão de Segurança da Informação e Comunicações da Administração Pública Federal, direta e indireta, poderá apresentar sugestões de melhorias ou denúncias de quebra de segurança que deverão ser averiguadas pelas autoridades.

Art. 9º Esta Instrução Normativa entra em vigor sessenta dias após sua publicação.

�������������� �������������