[FUG-BR] RES: Redundancia e Balanceamento
Renata Dias
renatchinha em gmail.com
Quarta Janeiro 28 23:26:54 BRST 2009
Renato,
Gostaria de agradecer pelo email tão bem explicado. Muito obrigada
mesmo!!
Vou fazer aqui e depois mando a resposta p/ vcs!
Valew
Renata Dias
2009/1/28 Renato Frederick <frederick em dahype.org>
> Renata,
>
> Antes de tudo, Sugiro usar o 1o ip do bloco CIDR obtido como neighbor.
> Exemplo, se você ganhou um 100.100.0.0/20, usar o 100.100.0.1 como peer.
>
> Aliás, é o recomendado por diversas operadoras nos formulários de inclusão.
> Um dos motivos mais fortes que vejo para tanto é: caso seu circuito algum
> dia mude até fisicamente, sua sessão BGP não necessitara reconfiguração.
> Ao
> passo que o endereço /30 do router pode ser alterado ao mudar de tipo de
> enlace, ponta "B" na operadora, e por aí vai.
> Por experiência própria, quando mudamos de endereço, o tipo de protocolo de
> enlace foi alterado e a operadora não pôde manter o mesmo endereço entre as
> WAN dos roteadores, e ainda houve burocracia de manter o mesmo range /25 na
> época. Creio que houve também um pouco de negligencia da operadora mas
> enfim, é bom evitar isto.
>
> Feito isto, você vai ligar para a Embratel e pedir a ativação do BGP. Ela
> lhe enviara um formulário e você preenchera seu ASN, seu bloco CIDR, o IP
> da
> sua ponta que fechará a sessão BGP, contatos técnicos e por aí vai.
>
> Fará o mesmo para a operadora B.
>
> Você pedirá fullrouting, pois com fullrouting você pode ter controle
> granular sobre como e para quem a saída se originará, baseado no ASN de
> destino, coisa impossível com partial routing.
> Exemplo, para o ASN9999 sair pela Embratel, para o ASN8888 sair pela
> operadora B, fazer um Black role para o ASN4444 e tal.
>
> Enquanto a operadora faz os tramites internos, você já pode configurar em
> seu firewall, ou em seu rotador a sessão BGP. Já postei aqui e na GTER um
> "show running" de minha sessão, mas enviarei abaixo de novo.
>
> Lembre-se que fullrouting exige memória RAM, então, caso seu roteador seja
> obsoleto, ou com pouca RAM ou ainda já esteja chegando no limite de
> processamento, você pode rodar o BGP em cima do zebra(obsoleto) ou do
> quagga(recomendado), em cima do Freebsd. Ou ainda utilizar Mikrotik ou
> qualquer Linux com o quagga.
>
> Com o BGP configurado no router ou freebsd, você deixa ele desligado e
> quando a operadora te ligar, você sobe a sessão BGP e juntamente com o
> técnico deles, verifica se recebeu a tabela de rotas dos parceiros e se a
> operadora recebeu seu anuncio de bloco. Lembre-se que caso haja algum
> filtro
> de portas, é necessário abrir excessoes para o protocolo BGP.
>
> Terminado isto, é só colocar o IP de seu bloco CIDR em seus servidores da
> DMZ e, se for o caso, definir políticas de saída, que é algo bem poderoso.
> Por exemplo, pode-se definir que uma rede /24 sairá por um link e utilizará
> o outro como backup, pode-se definir que todas as redes usarão somente um
> link e que o outro ficará redundante, ou ainda pode-se fazer rotas baseadas
> em destino e por aí vai.
>
> Isto não compete á operadora, somente a você. Então, sugiro que primeiro
> suba-se a sessão BGP, para que a operadora possa terminar o chamado e só
> depois você comece a pensar nas políticas de divisão de
> tráfego/redundância.
>
>
> Abaixo um exemplo de configuração bgp com 2 operadoras, ignorando
> prefix-list e route-map, para simplificar:
>
> router bgp 28XXX
> no synchronization
> bgp router-id 187.X.X.1
> bgp log-neighbor-changes
> bgp dampening
> network 187.X.128.0 mask 255.255.248.0
> network 187.X.136.0 mask 255.255.248.0
> neighbor 200.X.0.X remote-as 6XXX
> neighbor 200.X.0.X description Transito BGP OPERADORA1
> neighbor 200.X.0.X ebgp-multihop 2
> neighbor 200.X.0.X update-source lo0
> neighbor 200.X.0.X soft-reconfiguration inbound
> neighbor 200.X.0.X prefix-list BOGONS in
> neighbor 200.X.0.X prefix-list ANUNCIAR out
>
> neighbor 200.Z.123.Z remote-as 1ZZZZ
> neighbor 200.Z.123.Z description Transito BGP OPERADORA2
> neighbor 200.Z.123.Z ebgp-multihop 6
> neighbor 200.Z.123.Z update-source lo0
> neighbor 200.Z.123.Z send-community both
> neighbor 200.Z.123.Z soft-reconfiguration inbound
> neighbor 200.Z.123.Z prefix-list BOGONS in
> neighbor 200.Z.123.Z prefix-list ANUNCIAR out
> no auto-summary
> !
> ip prefix-list ANUNCIAR description Blocos a serem anunciados
> ip prefix-list ANUNCIAR seq 5 permit 187.X.128.0/21
> ip prefix-list ANUNCIAR seq 10 permit 187.X.136.0/21
>
> !
> ip prefix-list BOGONS seq 10 deny 0.0.0.0/8 le 32
> ip prefix-list BOGONS seq 15 deny 10.0.0.0/8 le 32
> ip prefix-list BOGONS seq 20 deny 127.0.0.0/8 le 32
> ip prefix-list BOGONS seq 25 deny 172.16.0.0/12 le 32
> ip prefix-list BOGONS seq 30 deny 192.0.2.0/24 le 32
> ip prefix-list BOGONS seq 35 deny 192.168.0.0/16 le 32
> ip prefix-list BOGONS seq 40 deny 224.0.0.0/3 le 32
> ip prefix-list BOGONS seq 1000 deny 187.X.128.0/20 le 32
> ip prefix-list BOGONS seq 9999 permit 0.0.0.0/0 le 22
>
>
> para verificar se está OK, a saída do comando:
>
> # sh ip bgp summary
>
> Deverar ser algo assim:
>
> Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down
> State/PfxRcd
> 200.X.0.X 4 6XXX 5656318 100918 0 0 0 04:56:41 103127
> 200.Z.123.Z 4 1ZZZZ 4703616 101268 0 0 0 04:56:54 104552
>
> Note que a ultima coluna não deve ser 0. Caso contrário, indica que não
> está
> havendo recebimento de rotas.
>
> O estado também não pode estar como active. Ele precisa estar contando o
> tempo que a sessão esta estabelecida. O estado como active indica que a
> negociação começou mas não terminou.
>
> Bem, basicamente é isto, parece meio complexo no inicio mas é porque há
> muita informação desencontrada na NET.
>
> Abraços
>
>
>
> > -----Mensagem original-----
> > De: freebsd-bounces em fug.com.br [mailto:freebsd-bounces em fug.com.br] Em
> > nome de Renata Dias
> > Enviada em: quarta-feira, 28 de janeiro de 2009 17:29
> > Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)
> > Assunto: Re: [FUG-BR] Redundancia e Balanceamento
> >
> > Caros,
> >
> > Ja consegui esclarecer a questão de como fazer a replicação dos
> > dados,
> > porém tenho agora uma outra missão:
> >
> > Consegui com a operadora que meus dois circuitos de internet sejam
> > redundantes, mas para isso preciso configurar BGP nos dois roteadores
> > de
> > borda (atualmente FreeBSD).
> >
> > Recebi da operadora o seguinte email:
> >
> > -ASN a ser usado pelo cliente: 11111
> > -ASN da Embratel: 2222
> > -em cada BGP de cada circuito, cada um usará o ip de wan do outro como
> > neighbor BGP
> > -os PEs originarão, conforme pedido, a rota-default no BGP para os CPEs
> >
> > Encontrei no google diversos sites com documentos sobre o assunto e
> > estou
> > estudando, mas se alguem puder me dar uma ajuda mais prática sobre o
> > que
> > devo fazer nos meus servidores de borda já posso ativar o sistema
> > enquanto
> > entendo melhor como funciona.
> >
> > Obrigada!
> >
> >
> > 2009/1/21 Daniel Kühl <dklima em gmail.com>
> >
> > > Você pode fazer com NFS ou com storage, certamente a solução com
> > storage é
> > > muito mais elegante.
> > > O servidor MySQL suporta replicação.
> > >
> > >
> > > 2009/1/19 Renata Dias <renatchinha em gmail.com>
> > >
> > > > Caros,
> > > >
> > > > Necessito de auxilio para escolher o melhor conjunto de soluções
> > para
> > > > ativar um sistema de redundancia de servidores (podendo ou não
> > funcionar
> > > > com
> > > >
> > > > balanceamento de carga).
> > > > Os servidores são WEB e estão em locais distintos
> > geograficamente.
> > > >
> > > > A principio configurei o CARP para redundancia e PF para
> > balanceamento
> > > > round-robin, porém tenho a seguinte dúvida:
> > > >
> > > > 1) Caso o servidor BACKUP só tenha que assumir a função do MASTER
> > em caso
> > > > de
> > > >
> > > > queda no link, ou seja, sem balanceamento de carga, qual a melhor
> > forma
> > > do
> > > > servidor SLAVE manter-se atualizado com relação aos arquivos PHP
> > > > (/home/cliente) e a base de dados (mysql) ?
> > > > Quando o servidor MASTER ficar UP novamente e assumir as
> > atividades,
> > > como
> > > >
> > > > pegar de volta o que mudou enquanto ele estava DOWN?
> > > >
> > > > 2) Caso os dois servidores façam balanceamento (com PF round-
> > robin), como
> > > > manter o sincronismo do /home e da base de dados?
> > > >
> > > > Lembrando que as duas máquinas estão em locais diferentes e o
> > tempo de
> > > > latencia entre elas é em média de 20ms.
> > > >
> > > > Storage? raid+nfs ?
> > > >
> > > > Alguma luz???
> > > >
> > > > Obrigada!!
> > > > -------------------------
> > > > Histórico: http://www.fug.com.br/historico/html/freebsd/
> > > > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
> > > >
> > > -------------------------
> > > Histórico: http://www.fug.com.br/historico/html/freebsd/
> > > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
> > >
> > -------------------------
> > Histórico: http://www.fug.com.br/historico/html/freebsd/
> > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>
Mais detalhes sobre a lista de discussão freebsd