Archivi tag: Fiber Channel

BROCADE_fnl_TM

FabricOS e configurazioni

Nella gestione di una fabbrica fiber channel realizzata con switch Brocade (o assimilabili) si ha a che fare con il sistema FabricOS (ne abbiamo già parlato in un precedente articolo). Questo ha tutta una serie di comandi per creare e modificare la sua configurazione.

A differenza del Cisco IOS, nel FabricOS la sintassi di configurazione differisce dalla sintassi nella visualizzazione della configurazione stessa. Pertanto chi è abituato a Cisco IOS trova difficoltoso “copiare” una parte della configurazione da uno switch ad un altro osservandone semplicemente la configurazione tramite i comandi alishow, zoneshow e cfgshow.

È la classica situazione in cui si trova il sistemista che deve risolvere il conflitto di due fabbriche segmentate su una connessione ISL. La soluzione passa per la clonazione della configurazione su tutti gli switch interessati.

Il comando configupload, salvando la configurazione dello switch in un formato ASCII su un server FTP o via SCP, potrebbe tornarci utile (come in molti consigliano). Ma l’utilità si ferma al poter individuare  le differenze, e soltanto a patto di riordinare le righe della configurazione prima di eseguire tale ricerca.

Applicare le opportune modifiche non è cosa diretta.

Nel file (pur potendo scegliere tra configurazione intera e riduzione al  solo chassis o al solo switch) sono presenti informazioni non replicabili su tutti gli switch.

La replica della configurazione al fine di sanare una segmentazione deve considerare solo  alias, zone e configurazioni, non parametri dello chassis o dello switch che sono parametri univoci (e devono rimanere tali), come nome, indirizzo, id di dominio, ecc. Pertanto un file generato da uno switch non potrà essere caricato su di un altro, se non al fine di un disaster recovery.

Inoltre una zona (ad esempio) in questi file è espressa con la seguente:

zone.Prod1_C_CXPROD_SPA0:Prod1_Adapter_C;CX4_PROD_SPA0

che è cosa diversa dal comando per istruirla:

zonecreate "Prod1_C_CXPROD_SPA0", "Prod1_Adapter_C;CX4_PROD_SPA0"

La cosa ottimale sarebbe poter avere una traduzione del formato del file di configurazione scaricato dallo switch reputato “modello” e poterla replicare sugli altri dopo averli ripuliti con il comando cfgclear (come molti tutorial insegnano).

Pertanto ci sarà molto utile il seguente script, progettato proprio a questo scopo:

#!/bin/bash
#
# usage: create_FOS_config.sh
#
#
awk -F. '/^alias/{ print "alicreate \""substr($2,1, index($2,":") - 1)"\", \"" substr($2, index($2,":") + 1)"\"" }' $1 | sort -k2
awk -F. '/^zone/ { print "zonecreate \""substr($2,1, index($2,":") - 1)"\", \"" substr($2, index($2,":") + 1)"\"" }' $1 | sort -k2
awk -F. '/^cfg/ { print "cfgcreate \""substr($2,1, index($2,":") - 1)"\", \"" substr($2, index($2,":") + 1)"\"" }' $1

L’ordinamento impostato nell’elenco degli alias e delle zone potrà essere utile per un esame manuale del contenuto di questa parte della configurazione una volta caricata.

Spero possa essere utile.

tux+ibm

Linux e appliances

Mi è recentemente capitato di configurare degli switch FC IBM, modello 2498_24.
Nel verificare alcuni parametri di versione per la configurazione che mi accingevo a fare mi è andato l’occhio su un numero alquanto sospetto:

SAN:root> version
Kernel:     2.6.14.2
Fabric OS:  v6.4.2a
Made on:    Mon Jul 18 22:27:42 2011
Flash:        Tue Jan 3 17:18:42 2012
BootProm:   1.0.9

2.6.14 … interessante, mi dico. E mentre la parola Linux mi sovviene alla mente, mi ritornano certe polemiche mosse da certi “guru” sulla presunta pericolosità di adottare sistemi Linux nei comparti del networking e della sicurezza, ed è più sicuro affidarsi ad appliance da migliaia di euro (senza considerare licenze d’uso, upgrade, assistenze, ecc).
Ed eccomene una sotto mano, di queste appliance, e per di più costruita da “mamma IBM”, e chi ti trovo? Un bel sistema Linux con kernel 2.6: certo, customizzato, certo con tantissimi comandi ad hoc (vedi cosiddetto FOS) per il ruolo di questo dispositivo. Ma in finale sempre un kernel Linux.

Pertanto rido di quanti credano che comprare è meglio che realizzare in economia a partire da un semplice Linux box, specialmente per quei servizi che sono già completi e “di serie” quali un netfilter o altri elementi di livello kernel. Il resto sono pezzi di ferro da aggiungere tutto intorno.

Tanto per la cronaca; ecco altre dimostrazioni che un IBM 2498_24 è a tutti gli effetti un Linux box, customizzato e ridotto al minimo necessario.

SAN:root> uname -r
2.6.14.2
SAN:root> uname -a
Linux SAN 2.6.14.2 #1 Sat Jul 16 10:19:20 PDT 2011 ppc unknown
SAN:root> ls -l /
total 96
drwxr-xr-x   2 root     sys          4096 Jan  3  2012 bin/
drwxr-xr-x   2 root     sys          4096 Jan  3  2012 boot/
drwxr-xr-x   2 root     root         4096 Jan  3  2012 config/
drwxrwxrwx  41 root     sys          4096 Jan  3  2012 core_files/
drwxr-xr-x   3 root     sys          4096 Nov 13 12:28 dev/
lrwxrwxrwx   1 root     root           10 Nov 13 12:28 diag -> /proc/diag/
drwxr-xr-x  17 root     sys          4096 Jan 21 13:02 etc/
drwxr-xr-x   2 root     sys          4096 Jul 18  2011 export/
drwxr-xr-x  18 root     sys          4096 Nov 13 12:28 fabos/
drwxr-xr-x   2 root     sys          4096 Jul 18  2011 import/
drwxr-xr-x   2 root     sys          4096 Jul 18  2011 initrd/
drwxr-xr-x   6 root     sys          4096 Jan  3  2012 lib/
lrwxrwxrwx   1 root     sys            11 Jan  3  2012 libexec -> usr/libexec/
drwx------   2 root     root        16384 Jan  3  2012 lost+found/
drwxr-xr-x  24 root     root         4096 Jan  3  2012 mnt/
dr-xr-xr-x 214 root     root            0 Jan  1  1970 proc/
drwxr-x---   4 root     sys          4096 Jan  3  2012 root/
drwxr-xr-x   2 root     sys          4096 Jan  3  2012 sbin/
lrwxrwxrwx   1 root     sys             9 Jan  3  2012 share -> usr/share/
drwxr-xr-x   2 root     root         4096 Jan  3  2012 standby_sbin/
drwxrwxrwx   3 root     sys          4096 Jan  3  2012 support_files/
drwxr-xr-x   2 root     sys          4096 Jul 18  2011 tftpboot/
drwxrwxrwt   5 root     root            0 Jan 23 14:26 tmp/
drwxr-xr-x   2 root     sys          4096 Jul 18  2011 users/
drwxr-xr-x  11 root     sys          4096 Jan  3  2012 usr/
drwxr-xr-x  11 root     sys          4096 Jan  3  2012 var/

E vogliamo parlare di un

tail /var/log/nslog.txt
?

Va bene. Ogni altra considerazione è puramente superflua.

Il seguente articolo è anche disponibile nel seguente Blog

tux-banner

Linux & SAN

Premesso che lasceremo al lettore l’onere di trovare il software citato nel post nel sistema di pacchetti della distribuzione su cui opererà, diamo alcuni suggerimenti utili per la configurazione di connessioni a SAN per sistemi Linux.

Esistono molti modi per determinare le informazioni su indirizzi dell’HBA e mappature dei dischi, e in giro si trovano molti tutorial al riguardo.

Il punto finale può essere sempre considerato il seguente comando:

sg_map -x

che ci fornisce i nomi dei dispositivi a blocchi mappati su una qualche LUN.

Partiamo da qui per determinare altra informazione, in genere molto utile in sistemi complessi per orientarsi tra i vari dischi e storage: il nome dello storage e le WWN delle LUN.Ipotizziamo che la nuova LUN sia stata mappata sul dispositivo /dev/sda, quindi interroghiamo questo per determinare le informazioni richieste:

  • Informazioni sullo storage (produttorel,modello,S/N)
/lib/udev/scsi_id --page=0x80 --whitelisted \
--device=<b>/dev/sda</b> | awk '{ print substr($0,2)}'
  • Informazioni sulla LUN (WWN)
/lib/udev/scsi_id --page=0x83 --whitelisted \
--device=<b>/dev/sda</b> | awk '{ print substr($0,2)}'

Consigliamo di trascrivere queste due linee di codice in due distinti file, denominati scsi_storage_info e scsi_lun, dotarli di diritti di esecuzione e porli nel percorso /sbin (tutto quanto detto in questo post presuppone che siate amministratori delle macchine su cui operate). Avrete così altri comandi utili nel processo di configurazione di una connessione a SAN in un host Linux.