Everlinux's Blog » High Availability

Balanceamento de carga com Apache e Nginx

Tiago Cruz — Tue, 19 Jan 2010 17:00:29 +0000

Se você precisa balancear a carga em seu webserver e não tem (ou não pode usar) um hardware dedicado para isso, segue alguns exemplos práticos:

Apache httpd:

NameVirtualhost *:80
<VirtualHost *:80>
    ServerName everlinux-homolog.com
    ServerAlias 200.24.12.34 10.10.23.53 10.10.23.56
    ServerAdmin suporte@everlinux.com
    ErrorLog "|/usr/sbin/rotatelogs /var/log/httpd/error_log.%Y%m%d 86400 -180"
    CustomLog "|/usr/sbin/rotatelogs /var/log/httpd/access_log.%Y%m%d 86400 -180" combined
 
        <Proxy balancer://everhttp>
          BalancerMember http://10.10.23.53:80/ ping=10
          BalancerMember http://10.10.23.56:80/ ping=10
        Proxy>
 
ProxyPreserveHost on
ProxyPass / balancer://everhttp/
ProxyPassReverse /oii balancer://everhttp/
 
VirtualHost>

Nginx

http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  50;
 
      upstream everbalance {
         ip_hash;
         server 10.10.23.53 max_fails=3 fail_timeout=30s;
         server 10.10.23.56 max_fails=3 fail_timeout=30s;
         }
 
    server {
         listen  202.34.52.24:80;
         server_name  everlinux-homolog.com;
         location /
           {
            access_log   /var/log/nginx/hdig.log;
            proxy_pass   http://everbalance;
            proxy_set_header Host $host;
           }
         }
}

As linhas “ProxyPreserveHost on” (apache) e “proxy_set_header Host $host;” (nginx) são importantes caso sua aplicação trabalhe com o nome do domínio da URL para montar alguma coisa dinamicamente. Conteúdo estático geralmente não é necessário estas variáveis.

Como aumentar seu cluster online (ESX+GFS)

Tiago Cruz — Thu, 22 Jan 2009 22:28:19 +0000

Neste exemplo eu tenho um cluster em produção com a LUN compartilhada de 500 GB via GFS. Pretendo dobrar sua capacidade sem parada no sistema.

1-) Adicionar um “Mapped Raw LUN” no ESX, em Compatibility Mode “Physical”.
A “SCSI Controller” também precisa ser “Physical”, e o disco RAW precisa estar nesta controller dedicada

Ex:
Hard Disk 1 = SCSI Controller 0 = SCSI (0:0)
Hard Disk 2 = SCSI Controller 1 = SCSI (1:0)
Hard Disk 2 = SCSI Controller 1 = SCSI (1:1)

2-) Adicionar a LUN no Linux:

[root@cluster-02 ~]# cat /proc/scsi/scsi 
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: VMware   Model: Virtual disk     Rev: 1.0 
  Type:   Direct-Access                    ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 00 Lun: 00
  Vendor: IBM      Model: 1815      FAStT  Rev: 0914
  Type:   Direct-Access                    ANSI SCSI revision: 05
 
[root@cluster-02 ~]# echo "scsi add-single-device 1 0 1 0" > /proc/scsi/scsi
 
[root@cluster-02 ~]# cat /proc/scsi/scsi 
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: VMware   Model: Virtual disk     Rev: 1.0 
  Type:   Direct-Access                    ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 00 Lun: 00
  Vendor: IBM      Model: 1815      FAStT  Rev: 0914
  Type:   Direct-Access                    ANSI SCSI revision: 05
Host: scsi1 Channel: 00 Id: 01 Lun: 00
  Vendor: IBM      Model: 1815      FAStT  Rev: 0914
  Type:   Direct-Access                    ANSI SCSI revision: 05

Sendo: Host – Channel – ID – Lun
(um reboot também funcionaria )

3-) Configurar o Cluster de LVM

3a-) Criando um Logical Volume

# fdisk /dev/sdc (usar ID 8e = Linux LVM)
# partprobe (em todas as maquinas do cluster)
# lvmconf --enable-cluster
# pvcreate /dev/sdb1
# vgcreate -Ay -cy pre_homolog /dev/sdb1
# lvcreate -L 499G -n hotsites pre_homolog

3b-) Aumentando um já existente

[root@cluster-01 ~]# pvs
  PV         VG          Fmt  Attr PSize   PFree
  /dev/sdb1  pre_homolog lvm2 a-   499.99G 1016.00M
  /dev/sdc1              lvm2 --   499.99G  499.99G
 
[root@cluster-01 ~]# vgextend pre_homolog /dev/sdc1
  Volume group "pre_homolog" successfully extended
 
[root@cluster-01 ~]# vgs
  VG          #PV #LV #SN Attr   VSize   VFree  
  pre_homolog   2   1   0 wz--nc 999.98G 500.98G
 
[root@cluster-01 ~]# pvs
  PV         VG          Fmt  Attr PSize   PFree
  /dev/sdb1  pre_homolog lvm2 a-   499.99G 1016.00M
  /dev/sdc1  pre_homolog lvm2 a-   499.99G  499.99G
 
[root@cluster-01 ~]# lvextend -Ay -l+128252 /dev/pre_homolog/hotsites
  Extending logical volume hotsites to 999.98 GB
  Logical volume hotsites successfully resized
 
[root@cluster-01 ~]# lvs
  LV       VG          Attr   LSize   Origin Snap%  Move Log Copy%  Convert
  hotsites pre_homolog -wi-ao 999.98G
 
[root@cluster-01 ~]# vgs
  VG          #PV #LV #SN Attr   VSize   VFree
  pre_homolog   2   1   0 wz--nc 999.98G    0
 
[root@cluster-01 ~]# pvs
  PV         VG          Fmt  Attr PSize   PFree
  /dev/sdb1  pre_homolog lvm2 a-   499.99G    0
  /dev/sdc1  pre_homolog lvm2 a-   499.99G    0

4-) Aumentar o GFS

Com o /gfs montado, usando o gfs_grow

[root@cluster-01 ~]# gfs_grow -v /gfs
FS: Mount Point: /gfs
FS: Device: /dev/mapper/pre_homolog-hotsites
FS: Options: rw,hostdata=jid=0:id=131073:first=0
FS: Size: 130809855
RGRP: Current Resource Group List:
RI: Addr 130744354, RgLen 5, Start 130744359, DataLen 65496, BmapLen 16374
RI: Addr 130678852, RgLen 5, Start 130678857, DataLen 65496, BmapLen 16374
RI: Addr 130613350, RgLen 5, Start 130613355, DataLen 65496, BmapLen 16374
...
...
RI: Addr 261895985, RgLen 15, Start 261896000, DataLen 243904, BmapLen 60976
RGRP: 539 Resource groups in total
Preparing to write new FS information...
Done.

Antes:

[root@cluster-02 ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             6.9G  1.8G  4.7G  28% /
tmpfs                 1.9G     0  1.9G   0% /dev/shm
/dev/mapper/pre_homolog-hotsites
                      493G   12G  482G   3% /gfs

Depois:

[root@cluster-02 ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             6.9G  1.8G  4.7G  28% /
tmpfs                 1.9G     0  1.9G   0% /dev/shm
/dev/mapper/pre_homolog-hotsites
                      994G   12G  983G   2% /gfs

Cluster com VMware ESX + GFS

Tiago Cruz — Tue, 06 Jan 2009 23:26:47 +0000

Já escrevemos bastante sobre Virtualização usando Xen e Cluster aqui no Blog.

Desta vez, para começar bem 2009 eu irei apenas citar alguns testes que fiz usando VMware ESX com GFS, em um Storage compartilhado, usando tecnologia Red Hat 5.2 x86_64 com um Fence_VMWare Tech Preview do RHEL 5.3 beta.

O Problema

Eu já o utilizava o GFS com Xen ou até mesmo com DRBD em Muti-Master, porém o grande problema é que não existia um fence para vmware que funcionasse a contento.

O fence_vmware, escrito em perl parou no tempo em Agosto de 2007 e fora que a VMware Perl API necessária não compila em 64 bits.

A Red Hat pretende lançar agora no RHEL 5.3 um fence_vmware re-escrito em Python, porém ele ainda não trabalha com Cluster, pois conecta-se direto na máquina física, e não no VMCenter.

A Solução

A solução é utilizar o vmware_fence_vi, também da Red Hat que está em fase de desenvolvimento atualmente, que conecta no Virtual Center e não na máquina física que pode estar morta

Segue o /etc/cluster/cluster.conf utilizado nos testes:

Configuração do Cluster

<cluster alias="Cluster_GFS" config_version="10" name="Cluster_GFS">
	<fence_daemon clean_start="0" post_fail_delay="0" post_join_delay="3"/>
<cman>
    <multicast addr="224.0.0.1" interface="eth1"/>
cman>
	<clusternodes>
		<clusternode name="cluster-01-node-01" nodeid="1" votes="1">
			<multicast addr="224.0.0.1" interface="eth1"/>
	           <fence>
        	        <method name="single">
                	        <device name="node-01"/>
	                method>
	           fence>
                clusternode>
                <clusternode name="cluster-01-node-02" nodeid="2" votes="1">
			<multicast addr="224.0.0.1" interface="eth1"/>
                   <fence>
                        <method name="single">
                                <device name="node-02"/>
                        method>
                   fence>
                clusternode>
                <clusternode name="cluster-01-node-03" nodeid="3" votes="1">
			<multicast addr="224.0.0.1" interface="eth1"/>
                   <fence>
                        <method name="single">
                                <device name="node-03"/>
                        method>
                   fence>
                clusternode>
	clusternodes>
	<fencedevices>
		<fencedevice agent="fence_vmware_vi" ipaddr="10.107.113.2" login="user" name="node-01" passwd="xxxxx" port="Cluster_01_Node_01"/>
		<fencedevice agent="fence_vmware_vi" ipaddr="10.107.113.2" login="user" name="node-02" passwd="xxxxx" port="Cluster_01_Node_02"/>
		<fencedevice agent="fence_vmware_vi" ipaddr="10.107.113.2" login="user" name="node-03" passwd="xxxxx" port="Cluster_01_Node_03"/>
	fencedevices>
cluster>

Notas:

1-) Troque parênteses por sinal de maior/ menor (maldito wordpress!)

2-) O IP 10.107.113.2 é o IP do Virtual Center. Ele sempre sabe onde a máquina virtual se encontra, mesmo que ela for migrada para outro host físico.

3-) Forçamos o MultiCast pela eth1, que é uma interface dedicada para o heartbeat do Cluster. Algumas vezes o multicast tentava sair pela interface de loopback e cada máquina achava que estava sozinha no cluster

/etc/hosts dos servidores:

10.0.0.1 cluster-01-node-01 10.0.0.2 cluster-01-node-02 10.0.0.3 cluster-01-node-03 10.0.1.1 node-01 10.0.1.2 node-02 10.0.1.3 node-03

Script de escrita

Foi utilizado um script para escrever no storage compartilhado a cada segundo com o nome da máquina e a hora exata (minuto, segundo) da escrita.

# for i in `seq 1 1000`; do a=`echo $RANDOM | cut -c1-2`; dd if=/dev/zero of=/teste/`hostname -s`-`date +%H_%M_%S` bs=512k count=$a; sleep 1; done

Nós do Cluster

[root@cluster-01-node-02 ~]# cman_tool nodes Node Sts Inc Joined Name 1 M 60 2009-01-06 19:46:11 cluster-01-node-01 2 M 56 2009-01-06 19:46:11 cluster-01-node-02 3 M 68 2009-01-06 19:56:35 cluster-01-node-03

Fence Device

/sbin/fence_vmware_vi - DEVEL.1229423489
 
# The Following agent has been tested on:
# VI Perl API 1.6 against:
#       VMware ESX 3.5
#       VMware ESXi 3.5 update 2
#       VMware Virtual Center 2.5
#

Com a seguinte modificação na linha 13:

#sys.path.append("@FENCEAGENTSLIBDIR@")
sys.path.append("/usr/lib/fence")

Desligar máquina VIRTUAL

Teste: Desligar máquina VIRTUAL cluster-01-node-03

Resultado: GFS congelado por ~1 minuto

O que ocorreu: O fence_vmware_vi conectou no vmcenter e tirou a máquina do Cluster, liberando assim o I/O.

Desligar máquina FISICA normalmente

Teste: Desligar com reboot máquina FISICA 01 (que tinha a cluster-01-node-03)

Resultado: GFS congelado por ~2 minutos

O que ocorreu: Máquinas física iniciou o processo de reboot, a máquina virtual cluster-01-node-03 morreu e foi migrada e reiniciada em outro host físico.

PS: A máquina virtual não retornou ao seu host de origem quando a máquina física voltou

-rw-r--r-- 1 root root 44040192 Jan 6 2009 cluster-01-node-01-19_50_52 -rw-r--r-- 1 root root 15204352 Jan 6 2009 cluster-01-node-01-19_50_53 -rw-r--r-- 1 root root 10485760 Jan 6 2009 cluster-01-node-01-19_50_54 -rw-r--r-- 1 root root 41418752 Jan 6 2009 cluster-01-node-01-19_52_57 -rw-r--r-- 1 root root 17825792 Jan 6 2009 cluster-01-node-01-19_52_58 -rw-r--r-- 1 root root 23068672 Jan 6 2009 cluster-01-node-01-19_52_59 -rw-r--r-- 1 root root 6815744 Jan 6 2009 cluster-01-node-01-19_53_00 -rw-r--r-- 1 root root 49807360 Jan 6 2009 cluster-01-node-01-19_53_01 -rw-r--r-- 1 root root 10485760 Jan 6 2009 cluster-01-node-01-19_53_03

Desligar máquina FISICA brutalmente

Desligar com RESET (via RSA) máquina FISICA 02 (que tinha a cluster-01-node-03)

Resultado: GFS congelado por ~3 minutos

O que ocorreu: Máquinas física foi brutalmente desligada, a máquina virtual cluster-01-node-03 morreu e foi migrada e reiniciada em outro host físico.

O fence_vmware_vi tentou várias vezes tirar a máquina do cluster com falhas consecutivas pois a máquina não mais existia e o ESX demorou um pouco para entender o que estava acontecendo.

PS: A máquina virtual não retornou ao seu host de origem quando a máquina física voltou

-rw-r--r-- 1 root root 12058624 Jan 6 20:17 cluster-01-node-01-20_17_57 -rw-r--r-- 1 root root 11534336 Jan 6 20:17 cluster-01-node-01-20_17_58 -rw-r--r-- 1 root root 10485760 Jan 6 20:17 cluster-01-node-01-20_17_59 -rw-r--r-- 1 root root 5242880 Jan 6 20:18 cluster-01-node-01-20_18_00 -rw-r--r-- 1 root root 5767168 Jan 6 20:20 cluster-01-node-01-20_18_01 -rw-r--r-- 1 root root 6291456 Jan 6 20:21 cluster-01-node-01-20_21_00 -rw-r--r-- 1 root root 37748736 Jan 6 20:21 cluster-01-node-01-20_21_02 -rw-r--r-- 1 root root 17825792 Jan 6 20:21 cluster-01-node-01-20_21_03 -rw-r--r-- 1 root root 12582912 Jan 6 20:21 cluster-01-node-01-20_21_04 -rw-r--r-- 1 root root 34603008 Jan 6 20:21 cluster-01-node-01-20_21_05 -rw-r--r-- 1 root root 5242880 Jan 6 20:21 cluster-01-node-01-20_21_06 -rw-r--r-- 1 root root 12582912 Jan 6 20:21 cluster-01-node-01-20_21_07 -rw-r--r-- 1 root root 12582912 Jan 6 20:21 cluster-01-node-01-20_21_08

Trechos de logs

Jan  6 20:18:10 cluster-01-node-01 openais[2646]: [TOTEM] The token was lost in the OPERATIONAL state. 
Jan  6 20:18:10 cluster-01-node-01 openais[2646]: [TOTEM] Receive multicast socket recv buffer size (288000 bytes). 
Jan  6 20:18:10 cluster-01-node-01 openais[2646]: [TOTEM] Transmit multicast socket send buffer size (262142 bytes). 
Jan  6 20:18:10 cluster-01-node-01 openais[2646]: [TOTEM] entering GATHER state from 2. 
 
Jan  6 20:18:15 cluster-01-node-01 openais[2646]: [CLM  ] CLM CONFIGURATION CHANGE 
Jan  6 20:18:15 cluster-01-node-01 openais[2646]: [CLM  ] New Configuration: 
Jan  6 20:18:15 cluster-01-node-01 openais[2646]: [CLM  ] 	r(0) ip(10.0.0.1)  
Jan  6 20:18:15 cluster-01-node-01 openais[2646]: [CLM  ] 	r(0) ip(10.0.0.2)  
Jan  6 20:18:15 cluster-01-node-01 openais[2646]: [CLM  ] Members Left: 
Jan  6 20:18:15 cluster-01-node-01 fenced[2666]: cluster-01-node-03 not a cluster member after 0 sec post_fail_delay
Jan  6 20:18:15 cluster-01-node-01 openais[2646]: [CLM  ] 	r(0) ip(10.0.0.3)  
Jan  6 20:18:15 cluster-01-node-01 fenced[2666]: fencing node "cluster-01-node-03"
 
  Please use '-h' for usagcation=HASH(0x1df33bd0)ing with the remote host.eports: vmware_helper returned Cannot power off vm Cluster_01_Node_03!
Jan  6 20:18:47 cluster-01-node-01 fenced[2666]: agent "fence_vmware_vi" reports: e 
Jan  6 20:18:47 cluster-01-node-01 ccsd[2636]: Attempt to close an unopened CCS descriptor (44880). 
Jan  6 20:18:47 cluster-01-node-01 ccsd[2636]: Error while processing disconnect: Invalid request descriptor 
Jan  6 20:18:47 cluster-01-node-01 fenced[2666]: fence "cluster-01-node-03" failed
Jan  6 20:18:52 cluster-01-node-01 fenced[2666]: fencing node "cluster-01-node"
 
Jan  6 20:19:28 cluster-01-node-01 fenced[2666]: agent "fence_vmware_vi" reports: Connection timed out 
Jan  6 20:19:28 cluster-01-node-01 ccsd[2636]: Attempt to close an unopened CCS descriptor (45600). 
Jan  6 20:19:28 cluster-01-node-01 ccsd[2636]: Error while processing disconnect: Invalid request descriptor 
Jan  6 20:19:28 cluster-01-node-01 fenced[2666]: fence "cluster-01-node-03" failed
 
Jan  6 20:19:33 cluster-01-node-01 fenced[2666]: fencing node "cluster-01-node-03"
  Please use '-h' tNotConnected=HASH(0x19bb0090)mote host, since it is disconnected.ware_helper returned Cannot power on vm Cluster_01_Node_03!
Jan  6 20:19:46 cluster-01-node-01 fenced[2666]: agent "fence_vmware_vi" reports: for usage 
Jan  6 20:19:46 cluster-01-node-01 fenced[2666]: fence "cluster-01-node-03" failed
Jan  6 20:19:51 cluster-01-node-01 fenced[2666]: fencing node "cluster-01-node-03"
 
Jan  6 20:20:59 cluster-01-node-01 ccsd[2636]: Attempt to close an unopened CCS descriptor (46710). 
Jan  6 20:20:59 cluster-01-node-01 ccsd[2636]: Error while processing disconnect: Invalid request descriptor 
Jan  6 20:20:59 cluster-01-node-01 fenced[2666]: fence "cluster-01-node-03.ig.com.br" success
Jan  6 20:20:59 cluster-01-node-01 kernel: GFS: fsid=Cluster_GFS:gfs.0: jid=2: Trying to acquire journal lock...
Jan  6 20:20:59 cluster-01-node-01 kernel: GFS: fsid=Cluster_GFS:gfs.0: jid=2: Looking at journal...
Jan  6 20:20:59 cluster-01-node-01 kernel: GFS: fsid=Cluster_GFS:gfs.0: jid=2: Acquiring the transaction lock...
Jan  6 20:20:59 cluster-01-node-01 kernel: GFS: fsid=Cluster_GFS:gfs.0: jid=2: Replaying journal...
Jan  6 20:20:59 cluster-01-node-01 kernel: GFS: fsid=Cluster_GFS:gfs.0: jid=2: Replayed 79 of 93 blocks
Jan  6 20:20:59 cluster-01-node-01 kernel: GFS: fsid=Cluster_GFS:gfs.0: jid=2: replays = 79, skips = 13, sames = 1
Jan  6 20:20:59 cluster-01-node-01 kernel: GFS: fsid=Cluster_GFS:gfs.0: jid=2: Journal replayed in 1s
Jan  6 20:20:59 cluster-01-node-01 kernel: GFS: fsid=Cluster_GFS:gfs.0: jid=2: Done

Conclusão

Estes testes foram realizados buscando alternativas que reduzam o downtime dos serviços e/ou aplicações contidos em um servidor, chegando a manter sua disponibilidade próxima dos 99,999%.

Como você pôde perceber, esta estrutura permite chegarmos a este número, mas até o momento em que está sendo escrito este post, a versão usada ainda não está homologada, usando pacotes ainda em desenvolvimento (cman+fence_vmware).

Num futuro próximo, já devemos ter algum retorno das empresas desenvolvedoras, pois focam em uma fatia do merdado muito forte e competitiva ($$$).

Mantendo sistemas “alive” com uso de Bond’s

Carlos Mangini — Fri, 21 Nov 2008 22:09:52 +0000

Recentemente precisei colocar um grupo de servidores em alta disponibilidade (High availability) e resolvi usar um recurso conhecido como “bond”.

Fácil de implementar, tudo que você irá precisar são 2 placas de rede, 2 cabos de rede, sendo cada um destes conectado a 1 switch. Dessa forma, um dos switch’s ficando indisponível, conseguiremos manter o Servidor atendendo à demanda.

Vamos as configurações:

Precisamos manter as configurações das 2 interfaces de rede sem IP’s. Isso acontece, porque o bond vai assumir as duas placas de rede ele pode balancear a carga de dados entre elas, a opção default do bond, ou no caso, fazer a soma dos links, ou seja, se tivermos cada interface trabalhando a 1Gb o “throughput” do link será de 2Gb.

Abaixo a conf de cada eth:

/etc/sysconfig/network-scripts/ifcfg-eth0
# Intel Corporation 82571EB Gigabit Ethernet Controller
DEVICE=eth0
BOOTPROTO=none
HWADDR=”seu MAC ADDRESS”
IPV6ADDR=
IPV6PREFIX=
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no

/etc/sysconfig/network-scripts/ifcfg-eth1
# Intel Corporation 82571EB Gigabit Ethernet Controller
DEVICE=eth1
BOOTPROTO=none
HWADDR=”seu MAC ADDRESS”
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no

Além da configuração das 2 eth’s, precisamos criar um arquivo com as configurações do bond.
Iremos chamá-lo de /etc/sysconfig/network-scripts/ifcfg-bond0 e seu conteúdo será:

#bond0
DEVICE=bond0
BOOTPROTO=none
ONBOOT=yes
NETWORK=10.10.4.0
NETMASK=255.255.255.0
IPADDR=10.10.4.1
USERCTL=no

Agora, para subirmos a interface de bond, precisamos setar algumas variáveis no arquivo /etc/modprobe.conf

alias bond0 bonding
options bonding max_bonds=1 mode=0 miimon=100

- A primeira linha, irá criar um alias para a interface virtual bond0 baseado nas informações contidas no arquivo /etc/sysconfig/network-scripts/ifcfg-bond0.
- A segunda linha diz max_bonds=1 para termos um bond no servidor e mode=0 onde os links onde os links trabalharão em balanceamento roudrobin. Caso queira aumentar somar o link, esse valor deverá ser alterado.

Caso seu servidor precise mais de um bond (4 ou mais placas de rede), você precisará aumentar o valor da variável max_bonds para o numero de bonds necessários.

Pronto! As configurações estão feitas, apenas reinicie a rede e você acaba de ter um servidor rodando com alta disponibilidade dos links de rede.

Você pode testar o balanceamento olhando o arquivo /proc/net/bonding/bond0. Rode o comando abaixo e tire um dos cabos. Em tempo real ele lhe informará se o link está down ou up de cada interface agregada ao bond

Para mais informações, consulte:
/usr/share/doc/iputils-20020927/README.bonding