Mudanças entre as edições de "Comissão de Informática"

De MediaWiki do Campus São José
Ir para navegação Ir para pesquisar
 
(74 revisões intermediárias por 3 usuários não estão sendo mostradas)
Linha 9: Linha 9:
  
 
==Curto Prazo==
 
==Curto Prazo==
 +
# Implementação da política de ''backup'' definida por esta comissão. 20/05. Vinicius.
 +
# (Re)Mapeamento dos pontos de rede: identificação. 20/05. Rafael.
 +
# Implementação da política de monitoramento . -. Vinicius e Rafael.
 +
# 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===
 
# Estabelecimento de uma política de ''backup'' dos servidores: arquivos de usuários e de sistema, relatórios, simulações. 03/05. Ederson.
 
# Estabelecimento de uma política de ''backup'' dos servidores: arquivos de usuários e de sistema, relatórios, simulações. 03/05. Ederson.
−
# Implementação da política de ''backup'' definida por esta comissão. 10/05. Vinicius.
 
−
# Estabelecimento de uma política de monitoramento dos computadores e serviços: prioridade de atendimento, tempo de atendimento, tempo de solução. 10/05. Ederson.
 
−
# Implementação da política de monitoramento . 24/05. Vinicius e Rafael.
 
−
# (Re)Mapeamento dos pontos de rede: identificação. ?. Rafael.
 
  
 
==Médio Prazo==
 
==Médio Prazo==
 
# Revisão da política de de distribuição de recursos entre as VMs. -. -.
 
# Revisão da política de de distribuição de recursos entre as VMs. -. -.
 
# Política de incentivo ao uso do VoIP. -. -.
 
# Política de incentivo ao uso do VoIP. -. -.
 +
# Propor métodos eficientes de divulgação intra-Instituto. -. -.
  
 
==Longo Prazo==
 
==Longo Prazo==
  
 
=Reuniões=
 
=Reuniões=
−
Sugestões de horário:
+
A partir das sugestões de horário:
−
<center>
 
 
{| border=1
 
{| border=1
 
|-
 
|-
Linha 33: Linha 35:
 
|-
 
|-
 
|}
 
|}
−
</center>
+
foi montado um [[Media:Comissao.zip|calendário de reuniões programadas]].
−
Calendário de reuniões programadas até o final do ano:
 
−
<center>
 
−
<googlecalendar>?showTitle=0&amp;height=600&amp;wkst=1&amp;bgcolor=%23FFFFFF&amp;src=hahfm7f77k125ratid7rpq15tc%40group.calendar.google.com&amp;color=%23182C57&amp;ctz=America%2FSao_Paulo" style=" border-width:0 " width="800" height="600" frameborder="0" scrolling="no"></googlecalendar>
 
−
</center>
 
  
 
==13/04==
 
==13/04==
Linha 50: Linha 48:
 
** Da [[Discussão:Comissão de Informática|lista de sugestões]], foram escolhidas duas atividades como urgentes em [[#Curto Prazo|curto prazo]]: ''backup'' e revisão do cabeamento estruturado.
 
** Da [[Discussão:Comissão de Informática|lista de sugestões]], foram escolhidas duas atividades como urgentes em [[#Curto Prazo|curto prazo]]: ''backup'' e revisão do cabeamento estruturado.
  
−
==03/03==
+
==03/05==
 
* Presentes: Ederson Torresini, Humberto José de Sousa, Leone Carmos Garcia.
 
* Presentes: Ederson Torresini, Humberto José de Sousa, Leone Carmos Garcia.
 
* Pauta: apreciação da política de [[#Backup|backup]] proposta nesta página.
 
* Pauta: apreciação da política de [[#Backup|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|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)''':
 +
*# Material permanente
 +
*# material de consumo
 +
*# 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 [http://www.cisco.com/en/US/products/ps6120/index.html Cisco ASA 5510] e os switches gerenciáveis D-Link. Na próxima segunda-feira, dia 13/06/11, a Adriana ([http://www.teltecnetworks.com.br/ 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=
 
=Políticas=
 
==''Backup''==
 
==''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 <ref>LIMONCELLI, T. et al. '''[http://www.amazon.com/Practice-System-Network-Administration-Second/dp/0321492668/ref=sr_1_2?ie=UTF8&s=books&qid=1304471928&sr=1-2 The Practice os System and Network Administration]'''. Addison-Wesley. 2a. ed. 2007. ISBN 0321492668.</ref>.
+
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 <ref>LIMONCELLI, T. et al. '''[http://www.amazon.com/Practice-System-Network-Administration-Second/dp/0321492668/ref=sr_1_2?ie=UTF8&s=books&qid=1304471928&sr=1-2 The Practice os System and Network Administration]'''. Addison-Wesley. 2a. ed. 2007. ISBN 0321492668.</ref>. 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===
 
===Tipos de dados===
Linha 66: Linha 103:
 
# 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.
 
# 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.
 
# 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.
 
# 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.
−
# 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 é incetivada.
+
# 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.
−
# 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.
+
# Cópias completas dos dados dos usuários com periodicidade mensal e rotação trimestral.
 +
# 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===
 
===Mecanismos de Recuperação===
Linha 75: Linha 113:
  
 
===Monitoramento e Relatórios===
 
===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. 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 <ref>PRESTON, W. C. '''[http://oreilly.com/catalog/9780596102463 Backup & Recovery]'''. O'Reilly Media. 2007. ISBN 0596102461.</ref>.
+
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 [http://www.gnu.org/software/mailman/index.html 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 <ref>PRESTON, W. C. '''[http://oreilly.com/catalog/9780596102463 Backup & Recovery]'''. O'Reilly Media. 2007. ISBN 0596102461.</ref>.
  
 
===Implementação===
 
===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 [http://rsync.samba.org/ rsync] espelhando o sistema de arquivos em mídia interna ou remota do servidor remoto de ''backup'' é recomendado.
+
* '''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 [http://rsync.samba.org/ 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.
+
* '''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 (<tt>cron</tt>), 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).
−
* '''Dados 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.
+
* '''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 dados de usuários, requer um controle mais apurado, sendo também recomendado o uso de Bacula - nesse caso, em outro ''pool'' de armazenamento.
+
* '''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:
 +
<center>
 +
<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>
 +
</center>
 +
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===
+
=Bibliografia=
 
<references/>
 
<references/>

Edição atual tal como às 21h14min de 12 de julho de 2011

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”