Comissão de Informática

De MediaWiki do Campus São José
Revisão de 21h14min de 12 de julho de 2011 por Etorresini (discussão | contribs) (→‎Reuniões)
(dif) ← Edição anterior | Revisão atual (dif) | Versão posterior → (dif)
Ir para navegação Ir para pesquisar

Ações

Há uma lista de sugestões que foi proposta na primeira reunião.

As ações devem conter:

  • Cor: preto para programado/pendente e vermelho para atrasado.
  • Descrição da ação.
  • Prazo de entrega.
  • Responsável(is).

Curto Prazo

  1. Implementação da política de backup definida por esta comissão. 20/05. Vinicius.
  2. (Re)Mapeamento dos pontos de rede: identificação. 20/05. Rafael.
  3. Implementação da política de monitoramento . -. Vinicius e Rafael.
  4. Estabelecimento de uma política de monitoramento dos computadores e serviços: prioridade de atendimento, tempo de atendimento, tempo de solução. -. Ederson.

Concluídas

  1. Estabelecimento de uma política de backup dos servidores: arquivos de usuários e de sistema, relatórios, simulações. 03/05. Ederson.

Médio Prazo

  1. Revisão da política de de distribuição de recursos entre as VMs. -. -.
  2. Política de incentivo ao uso do VoIP. -. -.
  3. Propor métodos eficientes de divulgação intra-Instituto. -. -.

Longo Prazo

Reuniões

A partir das sugestões de horário:

Turno Segunda Terça Quarta Quinta Sexta
Manhã 07:00-13:00 (Humberto)
07:30-09:00 (Leone)
09:45-11:30 (Leone)
09:00-12:00 (Ederson)		 07:00-13:00 (Humberto)
07:30-09:00 (Leone)
08:00-09:30 (Ederson)		 07:00-13:00 (Humberto)
10:00-11:30 (Sobral)
09:00-12:00 (Ederson)		 07:00-13:00 (Humberto) 07:00-13:00 (Humberto)
Tarde 13:00-17:00 (Humberto)
16:00-18:00 (Odilson)		 13:00-17:00 (Humberto)
13:30-17:30 (Emerson)
13:30-14:30 (Ederson)		 13:30-14:15 (Leone)
13:30-17:30 (Emerson)
16:00-18:00 (Odilson)		 13:00-15:00 (Sobral)
13:30-17:30 (Emerson)		 14:00-18:00 (Sobral)
14:30-18:30 (Ederson)

foi montado um calendário de reuniões programadas.

13/04

  • Presentes: Nicanor Cardoso, Ederson Torresini, Odilson Tadeu Valle, Emerson Ribeiro de Mello, Leone Carmo Garcia, Humberto José de Souza, Rafael Moro de Andrade.
  • Pauta:
    • Formação da Comissão de Informática para discutir as políticas no campus.
    • Listagem inicial dos serviços e atividades pendentes em caráter de urgência. A lista está na discussão desta página.

30/04

  • Presentes: Ederson Torresini, Odilson Tadeu Valle e Emerson Ribeiro de Mello.
  • Pauta:

03/05

  • Presentes: Ederson Torresini, Humberto José de Sousa, Leone Carmos Garcia.
  • Pauta: apreciação da política de backup proposta nesta página.

10/05

  • Presentes: Ederson Torresini, Humberto José de Sousa, Leone Carmos Garcia.
  • Pauta: definição do cabeamento estruturado como próxima série de ações a serem executadas.

13/05

  • Presentes: Ederson Torresini, Rafael Moro de Andrade e Vinicius Teixeira Coelho.
  • Pauta: definição de data de implementação da política de backup: sexta-feira, 20/05. Estabelecida estratégia para organizar o cabeamento estruturado, iniciando pela documentação dos pontos de rede e armários de Telecomunicações e principal, com término dessa primeira etapa na mesma data - prazo de 1 semana. Em particular, houve mudanças significativas nas áreas de trabalho e nos armários de Telecomunicações e princpal. Assim, esta Comissão fará um levantamento de toda a documentação disponível acerca do cabeamento - com a mesma data final de 20/05. Em seguida, listará as necessidades para identificar todos os pontos de rede nas áreas de trabalho e armários (de Telecomunicações e principal):
    1. Material permanente
    2. material de consumo
    3. Bolsas de caráter temporário

17/05

  • Presentes: Ederson Torresini, Humberto José de Sousa, Leone Carmos Garcia.
  • Pauta: discussão das próximas ações e integração com as disciplinas técnicas da Área de Telecomunicações.

18/05

  • Presentes: Ederson Torresini, Emerson Ribeiro de Mello, Odilson Tadeu Valle, Rafael Moro de Andrade, Vinicius Teixeira Coelho.
  • Pauta: discussão dos próximos passoa para a segmentação da rede, configuração das VLANs, endereçamento e roteamento IPv6 combinado com IPv4.

24/05

Não houve reunião.

27/05

Não houve reunião.

31/05

Não houve reunião.

01/06

  • Presentes: Ederson Torresini, Vinicius Teixeira Coelho.
  • Pauta: discussão sobre a implementação da política de backup.

07/06

Não houve reunião.

10/06

  • Presentes: Ederson Torresini, Vinicius Teixeira Coelho.
  • Pauta: discussão sobre documentação e implementação da segmentação da rede utilizando o recém-chegado roteador Cisco ASA 5510 e os switches gerenciáveis D-Link. Na próxima segunda-feira, dia 13/06/11, a Adriana (Teltec Networks) entrará em contato com a COINF para agendar um data de configuração do roteador. DOCUMENTAR: trabalho do Ricardo, configs. dos D-Link, etc. etc. mudança da rede em 118/29 (3560-ASA) e 64/27 (ASA-servidores na DMZ).

Políticas

Backup

A política está descrita da seguinte forma: primeira os dados são separados de acordo com a sua importância, taxa de atualização e possibilidade de recuperação (outras fontes e tempo para realizar essa operação). Em seguida, propõe-se uma forma de salvaguardar os dados contra falhas físicas de hardware, para redundância e para arquivamento [1]. Cabe destacar que somente ativos de rede e servidores terão cópias de proteção, as estações de trabalho não serão cobertas por este serviço.

Tipos de dados

  1. Software básico: ciclo lento de modificações. Pode ser facilmente recuperado com mídias descarregadas da Internet. Não requer controle de versão.
  2. Configuração de software básico: ciclo muito alto de modificações no início, passando a médio depois do período de estabilização. Boa parte do seu conteúdo pode ser recuperado com mídias descarregadas da Internet, entretanto pode haver várias intervenções de administrador de sistema nos dados originais, o que torna interessante o controle de versão.
  3. Dados de usuários: ciclo alto de modificações. Por ser de criação dos usuários finais, devem estar sob controle de versão ou cópias de um período de tempo.

Volume e Tempo de Armazenamento

  1. Apesar da facilidade de recuperação do software básico, o tempo para fazê-lo é proibitivo - dada a sua importância e disponibilidade requerida. Por isso, é recomendado pelo menos uma cópia em mídia remota com até 1 semana de validade para rápido resgate do sistema em situação de falha, como por exemplo corrompimento de sistema de arquivos ou muitos arquivos críticos apagados.
  2. Como arquivos de configuração sofrem várias modificações ao longo do dia, e podem ser aproveitados em outros sistemas, é interessante o uso de ferramentas que façam controle de versão: , marcação, diferença entre versões, reversão e outras funcionalidades. Pelo exposto, deve ter todas as suas versões catalogadas em mesmo repositório - de preferência esse último em servidor remoto com acesso controlado.
  3. Como os dados de usuários têm um volume significativamente maior que os anteriores, devem possuir uma validade de acordo com o volume possível para armazenamento. Entretanto, um número aceitável é de 28 cópias (4 semanas) com periodicidade diária em mídia segura e removível. Como isso gerar alta granularidade na recuperação, é interessante cópias completas dos dados de usuários com periodicidade semanal e cópias incrementais ao longo dos outros seis dias. A compressão dos dados é incentivada.
  4. Cópias completas dos dados dos usuários com periodicidade mensal e rotação trimestral.
  5. Por fim, é também interessante realizar anualmente uma cópia completa com todos os itens acima mencionados, a ser armazenada em mídia segura e removível. Rotação quinquenal.

Mecanismos de Recuperação

  1. Uma forma sugerida para recuperar sistemas em falha é sobrescrevê-lo com a última cópia funcional, uma vez que pode haver conflito entre bibliotecas e aplicativos quando mesclados os arquivos.
  2. Com o controle de versão dos arquivos de configuração, é possível reverter de um até todos os arquivos para a versão desejada.
  3. Uma vez indexadas as cópias (integrais) dos arquivos, será possível utilizar um sistema de consulta das versões catalogadas para recuperação, desde que definidos os arquivos e datas de gravação.

Monitoramento e Relatórios

A fim de garantir o funcionamento do serviço, é recomendado registrar as ações e disponibilizá-las em ambiente com controle de acesso, a fim de monitorar as ações de armazenamento e recuperação. Alternativamente, pode-se usar uma lista de discussão para envio dos relatórios e publicação do histórico via HTTP, como acontece com mailman. Além disso, sugere-se também criar simulações aleatórias de falha e sua respectiva recuperação, a fim de garantir o seu pleno funcionamento [2].

Implementação

  • Software básico: o uso de ferramentas simples de sincronização são suficientes, além de não requerem clientes com configuração complexa. O uso periódico com rsync sobre SSH para "espelhar" o sistema de arquivos em mídia interna ou remota do servidor remoto de backup, em horários de baixo tráfego na rede, é recomendado.
  • Configuração de software básico: sistemas de controle de versão distribuídos se adequam melhor a esse cenário, onde tem-se um repositório local (mesmo sistema operacional) para rápida catalogação/recuperação espelhado em servidor de backup remoto. Em segundo plano e periodicamente (cron), roda-se uma aplicação para catalogar as mudanças dos arquivos. Ao final do dia, todo o histórico de modificações (versões) será enviado ao servidor remoto de backup, tendo assim repositórios replicados com rápida recuperação (local) e proteção (remoto).
  • Arquivos de usuários: pelo volume dos dados, é preciso uma ferramenta cliente-servidor como Bacula, operando com cópias completas semanais - a fim de minimizar tempo de recuperação (várias fitas para fazê-lo) - associado a cópias incrementais ao longo da semana. É recomendado utilizar pelo menos duas fitas alternadamente com as cópias incrementais, prevenindo que falhas de ordem física se propaguem por todo o período.
  • Completo: uma cópia anual, com todos os itens acima mencionados, em mídia removível, para instrumentalizar possíveis auditorias ou recuperações de longo curso. Assim como os arquivos de usuários, requer um controle mais apurado, sendo também recomendado o uso de Bacula - nesse caso, em outro pool de armazenamento.

Exemplo de uso:

<graphviz> digraph Backup{ rankdir=LR

servidor1 [shape=Mrecord,label="<0>Servidor 1|<1>Bacula File|<2>rcs|<3>rsync"] backup [shape=Mrecord,label="<0>Backup|<1>Bacula Director|<2>Bacula File|<3>Bacula Storage|<4>HTTPS|<5>SSH"] fita [shape=record,label="<0>Fita|<1>LTO"]

backup:1 -> servidor1:1 [label="1: Adm. centralizada do Bacula"] servidor1:1 -> backup:3 [label="2: Arquivos de usuário"] servidor1:4 -> backup:4 [label="3: Arquivos de configuração"] servidor1:2 -> backup:5 [label="4: S.O."] backup:3 -> fita:1 [label="5"] } </graphviz>

Nesse cenário, embora sejam utilizadas três formas de backup (o que pode caracterizar falta da padrão), a proposta considera que haverá outra aplicações de administração de redes integradas a essa solução, tais como:

  • Correio Eletrônico;
    • Listas de discussão;
  • Gerência:
    • Monitoramento;
    • Contabilização;
    • Configuração - facilitada por ferramentas de controle de versão para padronização e uniformização dos serviços distribuídos em rede.

Para finalizar, essa proposta tem foco maior na recuperação dos dados ao invés do armazenamento e replicação remotos, por isso cada tipo de dado é projetado para ser resgatado da melhor forma possível:

  • Software básico: o mais rápido possível e sem configuração de aplicativo cliente.
  • Arquivos de configuração: versão de acordo com a versão (e datas) do software básico resgatado.
  • Arquivos de usuários: qualquer versão, a pedido do usuário, do(s) arquivo(s) solicitados para recuperação.

Cabeamento Estruturado

O cabeamento estruturado se divide nos seguintes setores:

  • Áreas de trabalho
  • Cabeamento horizontal
  • Armários de Telecomunicações
  • Cabeamento vertical
  • Armário principal
  • Entrada de facilidades

Com a expansão da rede lógica no campus, houve impacto visível na organização dos armários e identificação dos pontos de rede. Como esta Comissão prevê o uso de VLAN, MSTP e outras tecnologias na rede de computadores, é essencial a documentação atualizada e fiel à realidade dos pontos terminais e intermediários. E como estamos tratando de um cenário já instalado e que sofreu expansões, é preciso primeiramente analisar a documentação existente: plantas baixas, mapas, tabelas e outros. Em seguida, atualizar tais informações e disponibilizá-las.

Durantes as férias de Janeiro de 2011 foi efetuado pelos funcionários Vinicius e Rafael e pelo bolsita Mario Felipe um levantamento total dos pontos de rede em todas as dependencias do campus, o arquivo com as informações colhidas está em:

\\dk\ctic\Reestruturacao cabeamento 2011\MapeamentoRede.pdf

Através dele foi possivel mapear rapidamente sem muitos detalhes cerca de 95% de toda a estrutura de pontos de rede do Campus. Algumas anotações sobre a situação de cada ponto tambem foi colocado como observação local para complemento da situação atual.

Afim de realizar o trabalho completo de identificação, correção do cabeamento, organização dos racks e outros serviços correlacionados será necessário:

  • Capital Humano: 2 bolsistas de 4hs/diária por 2 meses ou mais.
  • Equipamentos : Alguns ja solicitados através de licitação porem ainda nao chegaram, outros que podem ser comprados diretamente por uma compra direta.

Em posse destes será possivel então iniciar seguintes trabalhos:

  • Etiquetagem dos pontos/espelhos de rede
  • Organização dos cabos nos racks
  • Substituição dos cabos defeituosos ou inapropriados

Bibliografia

  1. ↑ LIMONCELLI, T. et al. The Practice os System and Network Administration. Addison-Wesley. 2a. ed. 2007. ISBN 0321492668.
  2. ↑ PRESTON, W. C. Backup & Recovery. O'Reilly Media. 2007. ISBN 0596102461.
Disponível em “https://wiki.sj.ifsc.edu.br/index.php?title=Comissão_de_Informática&oldid=35009”