Um bom projeto de rede LAN precisa prover tolerância à falhas e, para isso, utiliza-se o recurso de enlaces fisicamente redundantes.

O problema fundamental é que esta topologia desprovida do protocolo spanning tree (STP) não funcionaria por causa de um efeito conhecido como loop que é descrito a seguir.

Para solucionar este problema foi desenvolvido o protocolo supracitado que cria um caminho único através do bloqueio de portas segundo determinados critérios.

Loop de Bridge

Suponha um switch ethernet funcionando como bridge entre dois segmentos de rede que acabaram de ser ligados conforme a ilustração 1:

Ilustração 1 – Representação de ligação entre segmentos com 1 bridge.

O que ocorrerá:

1. Inicialmente o switch desconhecerá os endereços dos computadores, então ele permitirá a passagem dos quadros entre os segmentos para poder “escutar” de onde vem a resposta e formar uma tabela que identificará que hosts estão em cada porta;

2. Em cada porta do switch será formado um domínio de colisão, ou seja, após a formação da tabela só passará para outro segmento quadros destinados a computadores fora do segmento ligado à porta em questão;

3. Exceção para a propagação de broadcasts, ou seja, sempre que qualquer dos hosts enviar um broadcast, todos os outros hosts de todos os segmentos ligados receberão este quadro.

Nesta situação não há redundância de links e, supondo que ocorresse algum defeito num dos componentes que liga o segmento 1 ao segmento 2, a comunicação não aconteceria.

O problema de loop aconteceria se fosse instalada redundância como mostrado na ilustração 2:

Nesta situação ocorreria:

1. Supondo que o PC1 envie um quadro para PC4;

2. Os switchs 1 e 2 receberiam este quadro na porta ligada ao segmento 1 e o passaria para a porta ligada ao segmento 2 e anotariam na tabela que o PC1 está no segmento 1;

3. O quadro enviado ao segmento 2 pelo PC1 sairá duas vezes no segmento 2, uma vez para cada switch, e o outro switch então “escutará” quadros do PC1 para PC4 também no segmento 2, entendo então que o PC1 então está no segmento 2 e a tabela é refeita;

4. Nesta altura, nenhum switch sabe onde está PC4 e os quadros ouvidos no segmento cuja origem é o PC1 e o destino é o PC4 vai de volta para o segmento 1;

5. De volta no segmento 1, os switchs reaprendem que o PC1 lá está e assim se forma o loop que não acabará até que um dos switchs seja removido da configuração;

A situação de loop interrompe o funcionamento de uma rede.

Descrição do Spanning Tree

Para resolver o problema de loop e manter a funcionalidade de redundância foi criado pelo IEEE 802.1d o protocolo Spanning Tree, ou STP.

O loop ocorre porque os switchs não sabem da presença de outros switchs paralelos, o STP permite que os switchs se conheçam e montem um único caminho para os quadros, as portas redundantes ficam então bloqueadas só entrando em funcionamento em situações específicas como falha ou mudança de custo.

Assim, o bloqueio de portas impede e loop e garante redundância em caso de falha, mas em compensação o caminho percorrido por um quadro pode ser maior que o necessário e os switchs não usam os enlaces redundantes.

Supondo uma infra-estrutura composta de três switchs como a da ilustração 3:

Ilustração 3 – Representação de rede em loop

Após a execução do STP, um dos caminhos é aberto e somente uma única direção (ou caminho) será possível, como na ilustração 4:

Ilustração 4 - Representação de rede sem loop

Funcionamento do STP

Num primeiro momento o protocolo STP elegerá entre os switchs (ou bridges) um que será considerado a raiz.

Para fazer isso, cada switch anunciará através de BDPU (Bridge Protocol Data Unit) que ele é o raiz, ocorrerá uma escolha da melhor opção para raiz baseada num campo do BDPU chamado ID de 8 bytes, 2 bytes para Prioridade de bridge e 6 bytes para o MAC.

O switch de menor ID será a raiz do spanning tree.

Se uma bridge sabe um ID melhor que o que ela está anunciando, ela pára de anunciar o atual e passa a encaminhar o BDPU do melhor. Isto é feito até que todas as bridges convertam para uma única opção.

A mensagem usada para eleger a bridge raiz é chamada de BDPU hello.

Todas as portas da bridge raiz são colocadas no estado de forwarding, ou seja, o estado que permite o encaminhamento de quadros.

Depois que a bridge raiz está definida, os demais switchs serão chamados de “não-raiz” e deverão identificar sua posição em relação à raiz por meio da seleção de uma porta raiz.

Foram definidos pelo IEEE custos para os enlaces, o custo varia de 0 à 255 (1 byte), a bridge raiz anuncia custo 0 e as demais bridges adicionam o custo do enlace ao quadro recebido, por exemplo, se uma bridge está ligada diretamente a raiz através de um enlace de custo 19, ela soma 0 (raiz) +19 (enlace) e sabe ser este o custo até a raiz. Uma outra bridge ligada a esta bridge não-raiz somará o valor do enlace (por exemplo, 100) até a bridge não-raiz ao custo de 19 (da bridge não-raiz) e terá então o custo para atingir a raiz de 119.

Porta raiz é a porta que permite alcançar a bridge raiz e porta designada é a porta que anuncia que através dela se pode chegar à raiz e o custo para isso.

Se em outra porta, chegar um custo menor para alcançar a raiz, o switch substitui o custo atual em memória pelo do novo caminho e esta outra porta passa a ser a porta raiz.

Supondo que, em um enlace, estejam conectados mais de um switch, será então necessário que se determine qual deverá encaminhar os quadros, ou seja, qual deles será a porta designada para o segmento.

A porta designada é escolhida com base no custo mais baixo para chegar à raiz e, em caso de empate, usa-se o ID da bridge e o ID da porta para selecionar a melhor opção.

As demais portas ligadas ao segmento que não foram designadas passarão para o estado de blocking, ou seja, não encaminharão quadros.

A ilustração 5 mostra um exemplo gráfico do que foi exposto:

Ilustração 5 – Representação de rede sem porta bloqueada

O que ocorre:

1. O Switch A será eleito raiz pois tem o menor ID e suas portas serão portas designadas;

2. A porta 1 do Switch B e C serão eleitas portas-raiz por terem custo 19;

3. A porta 2 dos switchs B e C receberão o custo de 19 e somarão ao custo do enlace que é 100 e saberiam que o custo para atingir o raiz através do outro switch seria de 119;

4. Ocorreria então uma eleição para determinar qual seria a porta designada e, como haveria empate pelo custo, o ID seria usada para desempatar, ficando a porta 2 do Switch C bloqueada e a porta 2 do Switch B como sendo a porta designada.

O resultado seria:

Ilustração 6 – Representação de rede com porta bloqueada

CONCLUSÃO

A disponibilidade é vinculada diretamente à lucratividade e produtividade de um negócio, panes podem gerar imensos prejuízos às corporações e ainda causar a demissão do técnico responsável.

Uma das maneiras de garantir a continuidade do funcionamento é a utilização de redundância de ativos críticos, que no caso estudado é alcançado com a utilização de dois (ou mais) ativos interligados e com o STP habilitado.

Por ser uma tecnologia de simples implementação e manutenção, cujo preço diminui gradativamente, a sua relação custo/benefício se torna cada vez mais favorável.

BIBLIOGRAFIA

BOYLES, Tim; HUCABY, David. CCNP Switching: Guia da Certificação do Exame. Rio de Janeiro: Alta Books, 2002.

BRIDGE linuxNet. Bridge. Disponível em <http://linux-net.osdl.org/index.php/Bridge>.

JUCÁ, Humberto. Técnicas avançadas de conectividade e Firewall em GNU/Linux. Rio de Janeiro: Brasport, 2005.

ODOM, Wendell. CCNA ICND: guia de certificação do Exame. Rio de Janeiro: Alta Books, 2005.

Olá!

Comecei a publicar hoje a minha monografia como página estática aqui no Blog, por enquanto só pude colocar o resumo, introdução e a bibliografia e você pode vê-las clicando aqui.

O tema é sobre Alta Disponibilidade em Banco de Dados usando tecnologia Oracle e acredito que é de interesse de muitos DBAs.

A medida que for inserindo novas partes, vou colocando posts para informar.

Este post é baseado num estudo que fiz na graduação.

A importância da utilização de VLANs são muitas, entre elas podemos citar QoS, domínios de broadcasts, segurança etc.

Neste texto, foi criado um laboratório para exemplificar o uso de VLAN em linux.

Foi usado um ambiente virtual VMWARE com 4 estações na mesma rede (192.168.200.0/24) e dois computadores funcionando como switch L2 com 3 interfaces de rede.

A distribuição usada foi a Fedora Core 5, kernel 2.6.15.

Para o funcionamento do switch foi usado o pacote de instalação para o Kernel 2.6.15 que pode ser encontrado no http://lisa.ines.ro.

A instalação é razoavelmente complexa e exige que, manualmente, rode-se um patch no código fonte do Kernel, faça alterações e se compile o Kernel e o pacote do software.

O projeto está em fase inicial e a documentação é precária e pouco esclarecedora – o projeto foi um trabalho de graduação que se concluiu em 2005.

O interessante é que, após a configuração, as VLANs funcionam adequadamente e o trunk também, como veremos a seguir.

O LABORATÓRIO

A Ilustração 1 mostra o laboratório criado:

Ilutração 1

Num primeiro momento apenas adicionei as interfaces no switch e não fiz nenhuma configuração adicional, nesta situação todas as estações se comunicavam o que demonstrou que a função de switch funcionou.

Depois criei as VLANs e imediatamente as estações pararam de se comunicar pois não havia porta na mesma VLAN no mesmo switch e ainda não havia o trunk.

Na última fase, foi habilitado o trunk e então o PC1 e PC3 se comunicaram e o PC2 e PC4 também, pois estavam no mesmo VID e não houve comunicação entre PC1 e PC4 e PC2 e PC3.

Depois foi alterada o VID da eth2 do Switch 1 para 3, e então o PC1, PC3 e PC4 passaram a “conversar”.

A ilustração 2 mostra a configuração do switch 1 inserida no /etc/rc.local.

Ilutração 2

Já a ilustração 3 mostra a configuração do switch 2:

Ilustração 3

A ilustração 4 é a tela capturada do VMWARE com as estações e switchs e a ilustração 5 é tela de sumário do VMWARE.

Ilustração 4

Ilustração 5

CONCLUSÃO

Demonstrou-se a implementação dos conceitos relacionados às VLANs e TRUNK e sua viabilidade em Linux.

A implementação do LISA ajuda ainda a consolidar conhecimentos em Linux de configuração de módulos e compilação do Kernel.

É claro que não se pode considerar colocar em produção um software em fase tão inicial de desenvolvimento, ainda mais porque switchs exigem alta performance que dificilmente seria garantida num PC.

No site http://www.o3magazine.com/articles/html/2006/net-lisa.html o autor informa que conseguiu fazer a implementação em Linux comunicando-se com switchs reais, fica então a sugestão para uma extensão do laboratório aqui criado.

O blog estava parado.

Neste intervalo meu filho nasceu e minha monografia ficou pronta.

Colocarei o texto integral da monografia em páginas estáticas aqui do blog, o assunto é alta disponibilidade em banco de dados e espero que ajude a quem se interessar pelo tema. A medida que for criando as páginas vou colocando posts para informar.

A partir de agora o blog aumenta de escopo para falar sobre qualquer assunto de tecnologia, e pretendo em breve postar sobre o Oracle 11g, mas não me privarei de postar sobre outras áreas ligadas à tecnologia que são do meu interesse, como música ou rede.

Iniciando e parando

1. Database Control

A. Para iniciar:

Entre no prompt de comando e digite:

[oracle@centos45 ~]$ emctl start dbconsole

Deverá aparecer a seguinte resposta:

Note o texto em vermelho, é por este link que você entrará no Database Control

B. Para parar:

[oracle@centos45 ~]$ emctl stop dbconsole

2. Listener:

A. Pelo prompt:

i. Iniciando:

[oracle@centos45 ~]$ lsnrctl start

Ler o resto desta entrada »

Criei uma página informando alguns livros em português sobre o BD Oracle e assuntos pertinentes, são estes que eu uso no meu trabalho, para escrever neste blog e também na minha monografia.

Existem muitos outros livros interessantes e seria muito injusto esgotar o tema numa bibliografia tão pequena, então, assim que eu for usando e achar que o livro merece ser lido, eu os incluirei na página.

Se alguém tiver alguma sugestão, por favor deixe um comentário.

Para acessar a página, clique aqui.

Neste laboratório vamos ver o que acontece na instance e nos arquivos ao inicializar e parar o banco de dados Oracle 10g.

Fase 1: Preparando para ver as mudanças no BD

Depois de ter preparado o laboratório e ter feito o snapshot, inicialize o CentOS e log como oracle.

Entre no diretório bdump (background dump):

[oracle@centos45 ~]$ cd $ORACLE_BASE/admin/orcl/bdump

Altere o nome do arquivo alert_orcl.log para alert_orcl.log.bkp:

[oracle@centos45 bdump]$ mv alert_orcl.log alert_orcl.log.bkp

Crie um novo arquivo vazio alert_orcl.log:

[oracle@centos45 bdump]$ touch alert_orcl.log

Use o commando “tail –f” para acompanhar as alterações no arquivo alert_orcl.log:

[oracle@centos45 bdump]$ tail -f alert_orcl.log

Fase 2: Startup, shutdown, alternância de modos e respectivos resultados nos logs

Abra uma nova janela de terminal e conecte no sqlplus como sysdba:

[oracle@centos45 ~]$ sqlplus / as sysdba

Você verá:

Ler o resto desta entrada »

O comando tail mostra as últimas 10 linhas de um arquivo.

Por exemplo:

[oracle@centos45 bdump]$ tail alert_orcl.log

Pode ainda ser usada algumas opções como:

· [oracle@centos45 bdump]$ tail –f alert_orcl.log

Com “-f”, o tail cumprirá sua missão original de mostrar as 10 linhas, mas não retornará ao prompt e ficará mostrando as linhas adicionadas ao arquivo a medida que aparecerem.

O -f é uma opção muito importante para acompanhar logs.

· [oracle@centos45 bdump]$ tail –n 20 alert_orcl.log

O “-n 20” indica que serão 20 linhas, ao invés de 10, a serem mostradas pelo tail.