Agregação de Links, o famoso Link Aggregation

Oh nooooo!!!!

Oh nooooo!!!!

Imagina aquele seu servidor de arquivos em sua rede, como uma alta demanda de acessos, tráfego de vários arquivos, de diferentes tamanhos e, principalmente, essencial para uma série de aplicativos e funções. Já pensou se seu servidor simplesmente fica fora do ar? Uma loucura né?

Uma das categorias de HA (High availability, em português alta disponibilidade) é a utilização de agregação de links. A agregação de links possui várias vantagens, algumas das principais são o aumento de throughput sem a necessidade de modificar sua rede física, utilizando vários conjuntos de portas de switch e do servidor, similiar a uma “soma” (mais para frente veremos que não é de fato uma soma, é similar) e claro a disponibilidade. Caso um dos links morra, o outro assume de forma que quase imperceptível.

Então vamos lá, para nosso laboratório, temos um switch Brocade Fast Iron ICX6430-24p e um equipamento com Debian instalado.

ICX6430-24_front_mr

No Linux, chamados de Bonding este tipo de configuração. O Bonding do Linux, possui seis formas de trabalhar diferentes. São elas (Em inglês):

  • Mode 0 (balance-rr)

This mode transmits packets in a sequential order from the first available slave through the last. If two real interfaces are slaves in the bond and two packets arrive destined out of the bonded interface the first will be transmitted on the first slave and the second frame will be transmitted on the second slave. The third packet will be sent on the first and so on. This provides load balancing and fault tolerance.
Mode 1 (active-backup)

This mode places one of the interfaces into a backup state and will only make it active if the link is lost by the active interface. Only one slave in the bond is active at an instance of time. A different slave becomes active only when the active slave fails. This mode provides fault tolerance.
Mode 2 (balance-xor)

Transmits based on XOR formula. (Source MAC address is XOR’d with destination MAC address) modula slave count. This selects the same slave for each destination MAC address and provides load balancing and fault tolerance.
Mode 3 (broadcast)

This mode transmits everything on all slave interfaces. This mode is least used (only for specific purpose) and provides only fault tolerance.

Mode 4 (802.3ad)

This mode is known as Dynamic Link Aggregation mode. It creates aggregation groups that share the same speed and duplex settings. This mode requires a switch that supports IEEE 802.3ad Dynamic link.

Mode 5 (balance-tlb)

This is called as Adaptive transmit load balancing. The outgoing traffic is distributed according to the current load and queue on each slave interface. Incoming traffic is received by the current slave.

Mode 6 (balance-alb)

This is Adaptive load balancing mode. This includes balance-tlb + receive load balancing (rlb) for IPV4 traffic. The receive load balancing is achieved by ARP negotiation. The bonding driver intercepts the ARP Replies sent by the server on their way out and overwrites the src hw address with the unique hw address of one of the slaves in the bond such that different clients use different hw addresses for the server.

Basicamente, acima temos todos os tipos de Bonding disponíveis para utilização.

Utilizaremos aqui o método 4, exatamente o que utiliza o 802.3ad, do qual necessita que a outra ponta também possua suporte a este (No nosso caso, nosso switch suporta). Há outros métodos, tudo depende da sua necessidade e aplicação. Já trabalhei bastante com LAG (Acrônimo de Link Aggregation) em vários projetos onde a taxa de dados era altíssima e a disponibilidade 24/7. O mais recomendado nesses casos, é utilizar esta forma.

Claro que em nosso exemplo, faremos algo simples, uma conexão entre um servidor de arquivos, mas o importante é o conceito. Em redes grandes, é bem provável que se encontre servidores com várias NIC’s, vários LAG’s espalhados por diversos switches. O LAG também pode ser efetuado entre Switches para altas taxas de transferência de dados, contingência e performance.

Cenário de nosso laboratório

Cenário de nosso laboratório

Primeiramente a configuração de nosso switch:

A linha da Brocade possui uma CLI muito similar a Cisco, claro que alguns comandos são diferentes, mas a lógica de configuração (Exemplo, enable, conf t, etc) é praticamente a mesma.

Utilizaremos as portas 9 e 10 para nosso teste.

enable

configure terminal

interface ethernet 1/1/9
link-aggregate configure key 10000
link-aggregate active
!
interface ethernet 1/1/10
link-aggregate configure key 10000
link-aggregate active

Vamos lá. Primeiramente entramos em cada interface e atribuimos uma key. Essa key é responsável por identificar qual grupo de LAG pertence a porta. Caso nosso switch tivesse mais que um LAG, teríamos de configurar keys diferentes para cada grupo de portas específico de cada LAG. (Exemplo: LAG 1 key 10000, LAG 2 key 10001, etc)

Configuração Server:

debian_splash

Em nosso servidor, primeiramente vamos instalar o seguinte módulo: ifenslave-2.6,

apt-get install ifenslave-2.6

em /etc/network/interfaces, vamos configurar nossas interfaces para Bond.

iface bond0 inet static
address 192.168.1.15
netmask 255.255.255.0
network 192.168.1.0
gateway 192.168.1.1
slaves eth0 eth1
bond_mode 802.3ad
bond_miimon 100
bond_downdelay 200
bond_updelay 200

Esta é basicamente a configuração de interfaces de Bond para nosso servidor. Praticamente é criada uma “única interface bond0”, da qual receberá o IP e como escrava, terá as interfaces eth0 e eth1. No caso de falha de uma das duas, a outra assume. Os valores de bond_miimon, downdelay e updelay são referentes ao “atraso” até que uma ação seja tomada para um eventual evento. Por exemplo uma queda de link, demorará x milisegundos para ser considerado como um link fora e redirecionar todo o tráfego para outra interface.

Para verificarmos se nosso Bond, vamos primeiro verificar nosso switch:

Status dos Link-Aggregate:
SSH@brocade#show link-aggregate
System ID: 748e.f8f2.44a0
Long timeout: 90, default: 90
Short timeout: 3, default: 3
Port [Sys P] [Port P] [ Key ] [Act][Tio][Agg][Syn][Col][Dis][Def][Exp][Ope]
1/1/9 1 1 10000 Yes L Agg Syn Col Dis No No Ope
1/1/10 1 1 10000 Yes L Agg Syn Col Dis No No Ope

As portas do Bond estão operacionais, vamos agora verificar em nosso servidor:

cat /proc/net/bonding/bond0

Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer2 (0)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 200
Down Delay (ms): 200

802.3ad info
LACP rate: slow
Min links: 0
Aggregator selection policy (ad_select): stable
Active Aggregator Info:
Aggregator ID: 1
Number of ports: 2
Actor Key: 17
Partner Key: 10000
Partner Mac Address: 74:8e:f8:f2:44:a0

Slave Interface: eth0
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 1
Permanent HW addr: 00:30:4f:88:8a:53
Aggregator ID: 1
Slave queue ID: 0

Slave Interface: eth1
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 1
Permanent HW addr: 00:22:4d:7c:f3:22
Aggregator ID: 1
Slave queue ID: 0

Pronto, está Up também! Inclusive fiz já os testes de queda de link, pode-se observar o Link Failure Count: 1 , contando 1 queda até o momento de cada interface.

Para fins de curiosidade e maior entendimento, na imagem abaixo é possível entender como é feito o processo de eleição de comunicação dos pacotes por cada interface:

conta_lacp

Por fim, vale ressaltar, tratando-se de LACP, 1 + 1 não é 2! A verdadeira performance em 802.3ad será sentida em múltiplas comunicações, ou seja vários clientes acessando um mesmo ponto final. (No nosso caso o servidor de arquivos). Dúvidas, sugestões, críticas, informações complementares??! Podem comentar!

Fontes:

Admin-Magazine

Wiki Debian

Linux – Storage – Virtualization

Wiki e Forum Brocade

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *