Configuração de disco do storage via HDLM

Sobre o Multi Path (HDLM) do Storage Hitachi

Conforme o desenho, pode-se observar que será necessário um software multipath para controlar os vários caminhos que os servidores “server-spo-la-1″ e “server-spo-la-2″ podem fazer para chegar até os discos do storage.

Para exemplificar, o server-spo-la-1 pode fazer os seguintes caminhos:
- Passar pela fibra saindo pela HBA0 até o Switch 1, e chegar no storage pela Controller 0, porta A;
- Passar pela fibra saindo pela HBA1 até o Switch 2, e chegar no storage pela Controller 0, porta B;
- Passar pela fibra saindo pela HBA1 até o Switch 2, e chegar no storage pela Controller 1, porta A;
- Passar pela fibra saindo pela HBA0 até o Switch 1, e chegar no storage pela Controller 0, porta B;

É aí que entra o HDML (Hitachi Dynamic Link Manager). O problema é que para cada caminho que o SO faz até o Storage, ele encontra discos e “pensa” que são discos diferentes. Portanto, se você tem 25 LUNs exportadas para o server-spo-la-1, ele irá “enxergar” 100 discos (25*4=100). Será algo parecido com isso:

root@server-spo-la-1 ~# fdisk -l 2> /dev/null | grep "38.6 GB"
Disk /dev/sdb: 38.6 GB, 38654705664 bytes
Disk /dev/sdc: 38.6 GB, 38654705664 bytes
Disk /dev/sdd: 38.6 GB, 38654705664 bytes
Disk /dev/sde: 38.6 GB, 38654705664 bytes
Disk /dev/sdf: 38.6 GB, 38654705664 bytes
Disk /dev/sdg: 38.6 GB, 38654705664 bytes
Disk /dev/sdh: 38.6 GB, 38654705664 bytes
Disk /dev/sdi: 38.6 GB, 38654705664 bytes
Disk /dev/sdj: 38.6 GB, 38654705664 bytes
Disk /dev/sdk: 38.6 GB, 38654705664 bytes
Disk /dev/sdl: 38.6 GB, 38654705664 bytes
Disk /dev/sdm: 38.6 GB, 38654705664 bytes
Disk /dev/sdn: 38.6 GB, 38654705664 bytes
Disk /dev/sdo: 38.6 GB, 38654705664 bytes
Disk /dev/sdp: 38.6 GB, 38654705664 bytes
Disk /dev/sdq: 38.6 GB, 38654705664 bytes
Disk /dev/sdr: 38.6 GB, 38654705664 bytes
Disk /dev/sds: 38.6 GB, 38654705664 bytes
Disk /dev/sdt: 38.6 GB, 38654705664 bytes
Disk /dev/sdu: 38.6 GB, 38654705664 bytes
Disk /dev/sdv: 38.6 GB, 38654705664 bytes
Disk /dev/sdw: 38.6 GB, 38654705664 bytes
Disk /dev/sdx: 38.6 GB, 38654705664 bytes
Disk /dev/sdy: 38.6 GB, 38654705664 bytes
Disk /dev/sdz: 38.6 GB, 38654705664 bytes
Disk /dev/sdaa: 38.6 GB, 38654705664 bytes
Disk /dev/sdab: 38.6 GB, 38654705664 bytes
Disk /dev/sdac: 38.6 GB, 38654705664 bytes
Disk /dev/sdad: 38.6 GB, 38654705664 bytes
Disk /dev/sdae: 38.6 GB, 38654705664 bytes
Disk /dev/sdaf: 38.6 GB, 38654705664 bytes
Disk /dev/sdag: 38.6 GB, 38654705664 bytes
…

Completamente bizarro

Instalação do HDLM

O processo de instalação é um tanto chato, e cada servidor precisa de uma licença diferente. Em termos gerais, seria mais ou menos isso:

-> Verificar se o server acha os discos com um fdisk -l

-> Copiar o license key para:
/var/tmp/hdlm_license
/etc/opt/DynamicLinkManager/dlm.lic_key

-> Rodar o /media/cdrom/installhdml

-> No /etc/profile

PATH=$PATH:/opt/DynamicLinkManager/bin ; export PATH

-> Reboot

-> Verificar se o fdisk -l mostra mais discos

Se tudo der certo, além dos 100 discos de outrora, seu servidor irá enxergar mais 25 (!!!) mas agora com outro nome. E será esse device que você irá utilizar para guardar os dados:

Disk /dev/sddlmaa: 38.6 GB, 38654705664 bytes
Disk /dev/sddlmab: 38.6 GB, 38654705664 bytes
Disk /dev/sddlmac: 38.6 GB, 38654705664 bytes
Disk /dev/sddlmad: 38.6 GB, 38654705664 bytes
Disk /dev/sddlmae: 38.6 GB, 38654705664 bytes
Disk /dev/sddlmaf: 38.6 GB, 38654705664 bytes
Disk /dev/sddlmag: 38.6 GB, 38654705664 bytes
Disk /dev/sddlmah: 38.6 GB, 38654705664 bytes
Disk /dev/sddlmai: 38.6 GB, 38654705664 bytes
Disk /dev/sddlmaj: 38.6 GB, 38654705664 bytes
Disk /dev/sddlmak: 38.6 GB, 38654705664 bytes
Disk /dev/sddlmal: 38.6 GB, 38654705664 bytes

…

Configuração do HDLM

Caso você queira testar se o HDML está mesmo funcionando, você poderia tirar uma fibra enquanto copia os dados, chutar o switch ou algo do tipo

# dlnkmgr set -lb on
# dlnkmgr set -pchk on -intvl 5
# dlnkmgr set -afb on -intvl 5
# dlnkmgr set -ellv 2
# dlnkmgr set -systflv 1
# dlnkmgr set -elfs 1000
# dlnkmgr set -elfn 5
# dlnkmgr set -systfs 2000
# dlnkmgr set -systfn 10

Para verificar:

# dlnkmgr view -path | more
# dlnkmgr view -sys
# dlnkmgr view -lu | more

Este setup irá ativar o Load Balance, verificação de PATH, auto Failback em caso de falhas e etc.

Configurando o LVM

Existe ainda mais um cuidado a ser tomado antes de você conseguir brincar com o Storage. O LVM é uma ferramenta muito esperta, e ele identifica cada disco com uma assinatura, individual e intransferível, mais ou menos como a sua impressão digital.

Portanto, ao adicionar um disco do HDLM ao LVM, você verá algo parecido com isso:

root@server-la-2 ~# pvcreate /dev/sddlmaa
Physical volume “/dev/sddlmaa” successfully created

root@server-la-2 ~# pvs
Found duplicate PV sXzKX9RMVxSafKzfDJP78Zr4qYFPNPcO: using /dev/sdb not /dev/sddlmaa
Found duplicate PV sXzKX9RMVxSafKzfDJP78Zr4qYFPNPcO: using /dev/sdch not /dev/sdb
Found duplicate PV sXzKX9RMVxSafKzfDJP78Zr4qYFPNPcO: using /dev/sdbf not /dev/sdch
Found duplicate PV sXzKX9RMVxSafKzfDJP78Zr4qYFPNPcO: using /dev/sdad not /dev/sdbf
Found duplicate PV sXzKX9RMVxSafKzfDJP78Zr4qYFPNPcO: using /dev/sddlmaa not /dev/sdad
PV VG Fmt Attr PSize PFree
/dev/sda2 Vol_LVM lvm2 a- 408.17G 0
/dev/sddlmaa lvm2 — 36.00G 36.00G

O que acontece é que o LVM está vendo o mesmo disco (mesma LUN, na verdade) pelos 04 caminhos diferentes e mais o novo caminho, do HDLM.

O que você deve fazer, é editar o arquivo /etc/lvm/lvm.conf e criar um filtro separando os devices que devem de fato serem manipulados pelo LVM, algo deste tipo:

filter = [ "a/sda1-9$/" "a/sddla-za-za-z$/" "r/.*/" ]

Após isso, basta rodar um ‘vgscan -vv’ para refazer o cache.

Passos rápidos para configurar o LVM no Storage

Papo rápido:


# for i in `fdisk -l 2> /dev/null | grep "sddl" | awk '{print $2}' | cut -d : -f 1`; do pvcreate $i; done



# vgcreate -Ay AMS500 /dev/sddlmaa /dev/sddlmab /dev/sddlmac /dev/sddlmad \
/dev/sddlmae /dev/sddlmaf /dev/sddlmag /dev/sddlmah /dev/sddlmai /dev/sddlmaj \
/dev/sddlmak /dev/sddlmal /dev/sddlmam /dev/sddlman /dev/sddlmao /dev/sddlmap \
/dev/sddlmba /dev/sddlmbb /dev/sddlmbc /dev/sddlmbd /dev/sddlmbe /dev/sddlmbf \
/dev/sddlmbg /dev/sddlmbh /dev/sddlmbi /dev/sddlmbj /dev/sddlmbk /dev/sddlmbl



# lvcreate -Ay -L 1.2T --name u01 AMS500

# mkfs.ext3 /dev/AMS500/u01

# mkdir /u01; mount /dev/AMS500/u01 /u01

Pronto! 1.2 TB para brincar

Ganhando desempenho fazendo Stripe no LVM

É possível fazer Stripe do lado do Sistema Operacional, visando um maior desempenho

Cada servidor está “enxergando” 28 LUNs do Storage, como se cada LUN fosse um disco.

Utilizei o “dd” para criar arquivos de 10 e 40 GB nos servidores, tanto na “Barriga” da máquina (Dell PowerEdge 2950 em RAID 10) quanto no Storage. Depois disso, irei utilizar nos servidores Stripes com granulação de 128 KB, sempre no FileSystem com Block Size de 4KB para comparar:

# Teste Storage Billing
# LVM padrão (sem stripe) e Block Size de 4KB

=> 10 GB com LVM default:
root@server-la-1 ~# Storage: 1m38.939s
root@server-la-1 ~# Barriga: 1m22.395s

root@server-la-2 ~# Storage: 1m57.203s
root@server-la-2 ~# Barriga: 1m15.134s

=> 40 GB com LVM default:
root@server-la-1 ~# Storage: 10m23.250s
root@server-la-1 ~# Barriga: 06m04.812s

root@server-la-2 ~# Storage: 11m22.150s
root@server-la-2 ~# Barriga: 06m01.234s

# lvcreate -Ay -i 28 -I 128 -l258020 –name u01 AMS500
# 28 Stripes com granulação de 128 KB cada (Block size=4096)

=> 10 GB com LVM + Stripe 128K
root@server-la-2 ~# Storage: 1m02.411s
root@server-la-2 ~# Barriga: 1m18.440s

=> 40 GB com LVM + Stripe 128K
root@server-la-2 ~# Storage: 4m49.578s
root@server-la-2 ~# Barriga: 5m50.452s

# lvcreate -Ay -i 28 -I 64 -l258020 –name u01 AMS500
# 28 Stripes com granulação de 64 KB cada (Block size=4096)

=> 10 GB com LVM + Stripe 64K
root@server-la-1 ~# Storage: 1m42.396s
root@server-la-1 ~# Barriga: 1m44.903s

=> 40 GB com LVM + Stripe 64K
root@server-la-1 ~# Storage: 5m04.977s
root@server-la-1 ~# Barriga: 5m55.737s

HBA Solaris

bash-2.03# luxadm probe
No Network Array enclosures found in /dev/es

Found Fibre Channel device(s):
Node WWN:50070e800475e108 Device Type:Disk device
Logical Path:/dev/rdsk/c5t50060E800475D109d0s2
Node WWN:50070e800475e108 Device Type:Disk device
Logical Path:/dev/rdsk/c5t50060E800475D109d1s2
Node WWN:50070e800475e108 Device Type:Disk device
Logical Path:/dev/rdsk/c5t50060E800475D109d2s2
Node WWN:50070e800475e108 Device Type:Disk device
Logical Path:/dev/rdsk/c5t50060E800475D109d3s2
Node WWN:50070e800475e108 Device Type:Disk device
Logical Path:/dev/rdsk/c5t50060E800475D109d4s2
Node WWN:50070e800475e108 Device Type:Disk device
Logical Path:/dev/rdsk/c5t50060E800475D109d5s2
Node WWN:50070e800475e108 Device Type:Disk device
Logical Path:/dev/rdsk/c5t50060E800475D109d6s2
Node WWN:50070e800475e108 Device Type:Disk device
Logical Path:/dev/rdsk/c5t50060E800475D109d7s2

HBA card WWN

# prtconf -vp | grep wwn
port-wwn: 2100001b.3202f94b
node-wwn: 2000001b.3202f94b
port-wwn: 210000e0.8b90e795
node-wwn: 200000e0.8b90e795

#prtconf -vp | more

Node 0xf00e2f80
assigned-addresses: 81000810.00000000.00000300.00000000.00000100.82000814.00000000.00100000.00000000.00002000.82000830.00000000.00140000.00000000.00040000
version: ‘QLA2460 Host Adapter Driver(SPARC): 1.11 10/03/05′
manufacturer: ‘QLGC’
model: ‘QLA2460 ‘
name: ‘SUNW,qlc’
port-wwn: 2100001b.3202f94b
node-wwn: 2000001b.3202f94b
reg: 00000800.00000000.00000000.00000000.00000000.01000810.00000000.00000000.00000000.00000100.02000814.00000000.00000000.00000000.00001000
compatible: ‘pci1077,140.1077.140.2′ + ‘pci1077,140.1077.140′ + ‘pci1077,140′ + ‘pci1077,2422.2′ + ‘pci1077,2422′ + ‘pciclass,c0400′ + ‘pciclass,0400′
short-version: ‘1.11 10/03/05′
#size-cells: 00000000
#address-cells: 00000002
device_type: ’scsi-fcp’
fcode-rom-offset: 0000aa00
66mhz-capable:
fast-back-to-back:
devsel-speed: 00000001
latency-timer: 00000040
cache-line-size: 00000010
max-latency: 00000000
min-grant: 00000040
interrupts: 00000001
class-code: 000c0400
subsystem-id: 00000140
subsystem-vendor-id: 00001077
revision-id: 00000002
device-id: 00002422
vendor-id: 00001077

Node 0xf00ee398
#size-cells: 00000000
#address-cells: 00000004
reg: 00000000.00000000
device_type: ‘fp’
name: ‘fp’

Node 0xf00eeaa0
device_type: ‘block’
compatible: ’ssd’
name: ‘disk’

Node 0xf00ef91c
assigned-addresses: 81001010.00000000.00000400.00000000.00000100.82001014.00000000.
version: ‘QLA2460 Host Adapter Driver(SPARC): 1.11 10/03/05′
manufacturer: ‘QLGC’
model: ‘QLA2460 ‘
name: ‘SUNW,qlc’
port-wwn: 210000e0.8b90e795
node-wwn: 200000e0.8b90e795
reg: 00001000.00000000.00000000.00000000.00000000.01001010.00000000.
compatible: ‘pci1077,140.1077.140.2′ + ‘pci1077,140.1077.140′ + ‘pci1077,140′ + ‘pci1077,2422.2′ + ‘pci1077,2422′ + ‘pciclass,c0400′ + ‘pciclass,0400′
short-version: ‘1.11 10/03/05′
#size-cells: 00000000
#address-cells: 00000002
device_type: ’scsi-fcp’
fcode-rom-offset: 0000aa00
66mhz-capable:
fast-back-to-back:
devsel-speed: 00000001
latency-timer: 00000040
cache-line-size: 00000010
max-latency: 00000000
min-grant: 00000040
interrupts: 00000001
class-code: 000c0400
subsystem-id: 00000140
subsystem-vendor-id: 00001077
revision-id: 00000002
device-id: 00002422
vendor-id: 00001077

Node 0xf00fad34
#size-cells: 00000000
#address-cells: 00000004
reg: 00000000.00000000
device_type: ‘fp’
name: ‘fp’

Node 0xf00fb43c
device_type: ‘block’
compatible: ’ssd’
name: ‘disk’

For Solaris 8 and 9:
Run the following script to determine the WWNs of the HBAs that are currently being utilized:
#!/bin/sh for i in `cfgadm |grep fc-fabric|awk ‘{print $1}’`;

do

dev=”`cfgadm -lv $i|grep devices |awk ‘{print $NF}’`” wwn= \

“`luxadm -e dump_map $dev |grep ‘Host Bus’|awk ‘{print $4}’`”

echo “$i: $wwn” done

To show link status of card

bash-2.03# luxadm -e port

Found path to 2 HBA ports

/devices/ssm@0,0/pci@18,700000/SUNW,qlc@2/fp@0,0:devctl CONNECTED
/devices/ssm@0,0/pci@19,700000/SUNW,qlc@2/fp@0,0:devctl CONNECTED

To see the WWN’s (using address given to you from previous commands),

it is the last one that specifies it is a HBA, so the port WWN here is 50070e800475e108

bash-2.03# luxadm -e dump_map /devices/ssm@0,0/pci@18,700000/SUNW,qlc@2/fp@0,0:devctl
Pos Port_ID Hard_Addr Port WWN Node WWN Type
0 642113 0 50070e800475e108 50070e800475e108 0×0 (Disk device)
1 643f13 0 550070e800475e108 50070e800475e108 0×0 (Disk device)
2 643913 0 2100001b3205e828 2000001b3205e828 0×1f (Unknown Type,Host Bus Adapter)

SAN Foundation Software versions display as such

bash-2.03# modinfo | grep SunFC
38 102bcd25 209b8 150 1 fcp (SunFC FCP v20070703-1.98)
39 102d4071 855c - 1 fctl (SunFC Transport v20070703-1.41)
42 102ead69 164e0 149 1 fp (SunFC Port v20070703-1.60)
44 10300a79 cd574 153 1 qlc (SunFC Qlogic FCA v20070212-2.19)

To show Sun/Qlogic HBA’s

bash-2.03# luxadm qlgc

Found Path to 2 FC100/P, ISP2200, ISP23xx Devices

Opening Device: /devices/ssm@0,0/pci@18,700000/SUNW,qlc@2/fp@0,0:devctl
Detected FCode Version: ISP2312 Host Adapter fcode version 1.16 11/15/06

Opening Device: /devices/ssm@0,0/pci@19,700000/SUNW,qlc@2/fp@0,0:devctl
Detected FCode Version: ISP2312 Host Adapter fcode version 1.16 11/15/06
Complete

To show all vendor HBA’s

bash-2.03# luxadm fcode_download -p

Found Path to 0 FC/S Cards
Complete

Found Path to 0 FC100/S Cards
Complete

Found Path to 2 FC100/P, ISP2200, ISP23xx Devices

Opening Device: /devices/ssm@0,0/pci@18,700000/SUNW,qlc@2/fp@0,0:devctl
Detected FCode Version: ISP2312 Host Adapter fcode version 1.16 11/15/06

Opening Device: /devices/ssm@0,0/pci@19,700000/SUNW,qlc@2/fp@0,0:devctl
Detected FCode Version: ISP2312 Host Adapter fcode version 1.16 11/15/06
Complete

Found Path to 0 JNI1560 Devices.
Complete

Found Path to 0 Emulex Devices.
Complete

Administração do Veritas no Solaris

Neste artigo é sobre Administração com Veritas Volume Manager e Filesystem, mostrando que não é muito difícil administrar discos e filesystems com Veritas.

Usarei o Veritas Volume Manager e Filesystem 4.1 com Solaris 10.

Por que utilizar o Veritas Volume Manager e Filesystem?

Veritas tem várias vantagens e uma delas é que é muito mais fácil verificar se os discos estão ativos e verificar espaços. Veritas passa muita confiança na hora de adicionar e remover o discos, aumentar filesystems e decrementar tudo on-line.

Vamos começar a entender os comandos que serão utilizado para a criação de um filesystem.

Inicialmente vamos entender o conceito abaixo:

DG é um grupo de volume e pode consistir de um ou mais volumes físicos. Pode haver mais de um grupo de volume no sistema. Uma vez criado o grupo de volume, e não o disco, é a unidade básica de armazenamento de dados (um disco virtual compondo-se de um ou mais discos físicos).

LV é o volume lógico e pode conter um número de volumes físicos "discos" ou representar apenas uma porção de um volume físico. Uma vez criados, volumes lógicos podem ser utilizados como partições de disco regulares - para criar um sistema de arquivos ou um dispositivo de troca.

Para saber qual ou quais são os VG's "grupo de volumes" que estão configurado no sistema operacional, vamos utilizar o comando vxdg list, como podemos ver abaixo:

#vxdg list
NAME STATE ID
rootdg enabled 1143490758.6.guairaca

Poderíamos ter vários VG's. Neste caso só temos um VG.

Vamos verificar quanto tem de espaço para criarmos e/ou aumentar um filesystem.

# vxassist -g rootdg maxsize
Maximum volume size: 468807680 (228910Mb)

No VG rootdg tem 228Gbyte.

Bom, agora que já sabemos que temos 228Gbyte livres, vamos criar um filesystem para o client Oracle com 50Gbyte.

#vxassist -g rootdg make oracle_client 50g

O nome do Volume Lógico será oracle_client e o nome do filesystem pode ser qualquer um. Claro que tem que ser um bom senso.

# mkfs -F vxfs -o largefiles /dev/vx/rdsk/rootdg/oracle_client

Agora vamos criar um ponto de montagem. Neste caso será /oracle e é claro que poderíamos colocar qualquer nome.

#mkdir /oracle

Agora vamos montar o filesystem:

#mount -F vxfs /dev/vx/dsk/rootdg/oracle_client /oracle

Sempre que você criar um filesystem você terá que colocar no arquivo /etc/vfstab.

Agora é só mudar o dono do diretório oracle.

#chown oracle:dba /oracle

Bom pessoal, espero ter ajudado com este artigo. Abraços e até mais!

Fonte: Marcelo Barros (Plugmasters)

Veritas Volume Manager (Ajuda)

• Localização (PATH) dos comandos Veritas:

/etc/vx/bin

• Reconfigurar o Veritas:

# vxdctl enable

• Listar discos, volumes e status:

# vxdisk list
DEVICE TYPE DISK GROUP STATUS
EMC1_0 sliced disk01 diskgroup online
EMC1_1 sliced disk02 diskgroup online
c1t0d0s2 sliced rootdisk rootdg online
c1t1d0s2 sliced rootmirror rootdg online
c1t2d0s2 sliced - - online
c1t3d0s2 sliced - - online

• Criar um novo volume:

Ex: Criando um volume de 10 GB:

Se não especificar o diskgroup, por default, o volume será criado no rootdg

# vxassist make [volume name] 10240m

Especificando o diskgroup:

# vxassist -g [diskgroup] make [volume name] 10240m

• Espelhar um volume

# vxassist mirror [volume name]

• Listar informações detalhadas de um volume group:

# vxprint -g [diskgroup] -ht

• Criar filesystem no Solaris, caso não use o Veritas filesystem:

# newfs /dev/vx/rdsk/[diskgroup]/[volume name]

• Renomear um volume:

# vxedit -g [diskgroup] rename [old name] [new name]

• Remover um volume:

# vxassist -g [diskgroup] remove volume [volume name]

• Aumentar um filesystem (vxfs ou ufs)

Ex: Aumentando em 1 GB

# df -k /filesystem
Filesystem Kbytes used avail capacity Mounted on
/dev/vx/dsk/[diskgroup name]/[volume name] 10321884 10166012 52654 100% /filesystem

# /etc/vx/bin/vxresize -F [filesystem type] -g [disk group] [volume name] +1g

Referências:

1. 875-3053-10 - VERITAS Volume Manager, Command Line Interface, Administrator’s Guide: http://docs.filibeto.org/products-n-solutions/hardware/docs/pdf/875-3053-10.pdf
2. Basic VxVM Commands: http://eval.veritas.com/downloads/van/vm_quickref.pdf
3. vxresize man page: http://www.cuddletech.com/veritas/man/vxresize.m

Novo conteúdo para as provas Linux ( em abril )

Pessoal o conteúdo das provas de certificação a partir de abril é o que está descrito aqui: https://group. lpi.org/publicwi ki/bin/view/ Examdev/LPIC- 10x

Uso de vários caminhos de rede IP em um sistema do Solaris com regiões instaladas - Solaris 10

Como usar vários caminhos de rede IP em regiões não globais com IP exclusivo - Solaris 10.

Vários caminhos de rede IP (IPMP) em uma região de IP exclusivo é configurada da mesma maneira que na região global.

Você pode configurar uma ou mais interfaces físicas em um grupo de vários caminhos IP, ou grupo IPMP. Após configurar IPMP, o sistema monitora automaticamente as interfaces no grupo IPMP para verificar falhas. Se uma interface no grupo falhar ou for removida para manutenção, IPMP migrará automaticamente, ou falhará, os endereços IP da interface falha. O recipiente desses endereços é uma interface funcional no grupo IPMP da interface falha. O recurso de falha de IPMP preserva a conectividade e impede a interrupção de quaisquer conexões existentes. Adicionalmente, IPMP melhorar o desempenho geral da rede ao propagar automaticamente o tráfego de rede no conjunto de interfaces no grupo IPMP. Este processo é chamado de propagação de carga.

1. Torne-se superusuário ou assuma a função de administrador principal.

   Para criar a função e atribuí-la a um usuário, consulte Using the Solaris Management Tools With RBAC (Task Map) no System Administration Guide: Basic Administration .

2. Configure grupos IPMP como descrito em Configuring IPMP Groups no System Administration Guide: IP Services .

Como estender a funcionalidade de vários caminhos de rede IP para regiões não globais com IP compartilhado

Use este procedimento para configurar IPMP na região global e estenda a funcionalidade de IPMP para regiões não globais.

Cada endereço, ou interface lógica, deve ser associada a uma região não global quando você configura a região. Consulte Uso do comando zonecfg e Como configurar a região para obter instruções.

Este procedimento realiza o seguinte:

• As placas bge0 e hme0 são configuradas em um grupo.

• O endereço 192.168.0.1 é associado à região não global my-zone.

• A placa bge0 é defina como interface física. Assim, o endereço IP é hospedado no grupo que contém as placas bge0 e hme0.

Em uma região em execução, você pode usar o comando ifconfig para fazer a associação. Consulte Interfaces de rede com IP compartilhado e a página do manual ifconfig(1M).

É necessário ser administrador global na região global para executar este procedimento.

1. Torne-se superusuário ou assuma a função de administrador principal.

   Para criar a função e atribuí-la a um usuário, consulte Using the Solaris Management Tools With RBAC (Task Map) no System Administration Guide: Basic Administration .

2. Na região global, configure grupos IPMP como descrito em Configuring IPMP Groups no System Administration Guide: IP Services.

3. Use o comando zonecfg para configurar a região. Quando você configurar o recurso net, adicione o endereço 192.168.0.1 e a interface física bge0 e a configuração do roteador padrão à região my-zone:

   zonecfg:my-zone> add net zonecfg:my-zone:net> set address=192.168.0.1 zonecfg:my-zone:net> set physical=bge0 zonecfg:my-zone:net> set defrouter=10.0.0.1 zonecfg:my-zone:net> end

   Somente bge0 deve ser visível na região não global my-zone.

Se bge0 falhar subseqüentemente

Se bge0 falhar subseqüentemente e o endereço de dados bge0 falhar em hme0 na região global, os endereços de my-zone também migrarão.

Se o endereço 192.168.0.1 se mover para hme0, somente hme0 será visível agora na região não global my-zone. Esta placa será associada ao endereço 192.168.0.1 , e bge0 não será mais visível.

Configuração de IPMP (Multipath - Failover virtual de interfaces de rede) - Solaris

O IPMP (Multipath - Failover virtual de interfaces de rede) é uma ferramenta que foi disponibilizada a partir do Solaris 8 para garantir uma maior disponibilidade da conexão de rede.

Importante:
Duas placas de rede ( caso das placas QUAD-GIGA será necessário 2, pois senão não terá redundância)
3 endereços IP (1 para alta disponibilidade, os outros 2 serão usados um em cada interface)
Os 3 endereços IP devem ser cadastrados no arquivo /etc/hosts com .

Exemplo:

10.0.0.1 serv IP que será colocado em “alta disponibilidade”
10.0.0.2 serv_int1 # IP interno da primeira interface
10.0.0.3 serv_int2 # IP interno da segunda interface

É necessário a criação do grupo relacionadas as interfaceis de redes fisicas:

Usando como exemplo as interfaces hme0 e hme1 e o grupo PUB, temos:

Estando a interface hme0 já configurada como o IP de “alta disponibilidade”, digite os comandos:

# ifconfig hme0 group pub
# ifconfig hme0 addif serv_int1 netmask + -failover deprecated up

Obs.: após esse comando será criado uma interface virtual hme0:1 com o ip de serv_int1. O ip de serv já deverá estar na hme0.

Para a interface standby (hme1) digite os comandos:

# ifconfig hme1 plumb *(habilita a placa)
# ifconfig hme1 group pub
# ifconfig hme1 serv_int2 netmask + -failover deprecated standby up

Obs.: Os ip´s de serv e serv_int1 estarão na interface hme0 e o ip de serv_int2 estará na interface hme1. Caso a interface serv_int1 cair, o ip de serv passará para a interface hme1:1.
Quando o problema for sanado, o IP voltará automaticamente para a interface default.

Exemplo de ifconfig -a após a configuração do failover:

…
ce0: flags=9040843 mtu 1500 index 2
inet 10.0.0.1 netmask fffff000 broadcast 10.4.15.255
groupname pub
ether 0:3:ba:3:ca:b2

ce0:1: flags=1000843 mtu 1500 index 2
inet 10.0.0.2 netmask fffff000 broadcast 10.4.15.255

ce1: flags=69040843 mtu 1500 index 3
inet 10.0.0.3 netmask fffff000 broadcast 10.4.15.255
groupname pub
ether 0:3:ba:3:ca:7a
…

Obs.: Uma das interfaces fica em modo STANDBY, INACTIVE, ela será ativada e receberá o ip de alta disponibilidade caso ocorra algum problema na interface principal.

/var/adm/messages quando ocorre a troca:

Feb 15 16:24:14 amon genunix: WARNING: ce0: fault detected external to device; service degraded
Feb 15 16:24:14 amon genunix: WARNING: ce0: xcvr addr:0×01 - link down
Feb 15 16:24:14 amon in.mpathd[118]: The link has gone down on ce0
Feb 15 16:24:14 amon in.mpathd[118]: NIC failure detected on ce0 of group pub
Feb 15 16:24:14 amon in.mpathd[118]: Successfully failed over from NIC ce0 to NIC ce1

As configurações via linha de comando são esquecidas após um reboot do servidor, para preservar essas configurações no boot, edite /etc/hostname.hme0 e /etc/hostname.hme1.
Por exemplo:

/etc/hostname.hme0
serv_int1 netmask + broadcast + group pub deprecated -failover up
addif serv netmask + broadcast + failover up

/etc/hostname.hme1
serv_int2 netmask + broadcast + group pub deprecated -failover standby up

Depois reinicie o servidor e verifique se está funcionando corretamente retirando um cabo de rede de cada vez.

Dica: Se sua rede estiver com escassez de endereços IP, configure os IPs de serv_int1 e serv_int2 com IPs de outra rede, por exemplo 192.168.0.1 e 192.168.0.2, enquanto que serv fica com o IP 10.0.0.1 . Você perderá a funcionalidade de pingar em cada placa individualmente, mas economizará 2 IPs.