zpool attach [-f] pool device new_device
Attaches new_device to an existing zpool device. The
existing device cannot be part of a raidz configuration.
If device is not currently part of a mirrored configura-
tion, device automatically transforms into a two-way
mirror of device and new_device. If device is part of a
two-way mirror, attaching new_device creates a three-way
mirror, and so on. In either case, new_device begins to
resilver immediately.
Visualizzazione post con etichetta raid. Mostra tutti i post
Visualizzazione post con etichetta raid. Mostra tutti i post
martedì 16 febbraio 2010
domenica 31 gennaio 2010
Aix LVM: il quorum
LVM utilizza un sistema di gestione dei VG che potrebbe essere paragonato alle repliche di SVM.
Potrebbe ... in realtà non è proprio così.
L'insieme di VGDA e VGSA di ogni disco (PV) determina la consistenza del VG.
Il quorum è fissato al 51% di VGDA funzionanti.
Queste aree vengono spartite tra i PV del VG in questo modo:
1 disco = 2 VGDA
2 dischi = 2 VGDA sul primo, 1 VGDA sul secondo
3 dischi = 1 VGDA per disco.
Il risultato di questa logica di suddivisione mi ha lasciato piuttosto "disappointed". In pratica per far stare in piedi un mirror, questo deve avere almeno tre dischi e/o essere three-ways.
Niente soluzioni, che parrebbero scontate, tipo 2 dischi in mirror. Così facendo, il guasto o la rimozione di un PV farebbe cadere il castello.
Il quorum è, comunque, disattivabile, quindi in realtà un mirror two-ways su due PV è fattibile.
venerdì 15 gennaio 2010
Mirroring rootvg su aix
Aggiungere hdisk1 al Volume Group:
# extendvg rootvg hdisk1
Dire a lvm di fare un mirror:
# mirrorvg rootvg
0516-1804 chvg: The quorum change takes effect immediately.
0516-1126 mirrorvg: rootvg successfully mirrored, user should perform
bosboot of system to initialize boot records. Then, user must modify
bootlist to include: hdisk0 hdisk1.
Aggiungere il nuovo disco a quelli bootabili:
# bootlist -m normal hdisk0 hdisk1
Installare il necessario per bootare il nuovo mirror:
# bosboot -ad hdisk0
# bosboot -ad hdisk1
Voila, les jeux sont faites:
#lspv
hdisk0 003639ba5bd2ab8f rootvg active
hdisk1 005fd68c35102992 rootvg active
# extendvg rootvg hdisk1
Dire a lvm di fare un mirror:
# mirrorvg rootvg
0516-1804 chvg: The quorum change takes effect immediately.
0516-1126 mirrorvg: rootvg successfully mirrored, user should perform
bosboot of system to initialize boot records. Then, user must modify
bootlist to include: hdisk0 hdisk1.
Aggiungere il nuovo disco a quelli bootabili:
# bootlist -m normal hdisk0 hdisk1
Installare il necessario per bootare il nuovo mirror:
# bosboot -ad hdisk0
# bosboot -ad hdisk1
Voila, les jeux sont faites:
#lspv
hdisk0 003639ba5bd2ab8f rootvg active
hdisk1 005fd68c35102992 rootvg active
venerdì 27 marzo 2009
SMI e EFI label
Per cambiare la label di un disco è necessario usare il comando format in modalità enhanced.
# format -e
format> label
[0] SMI Label
[1] EFI Label
Specify Label type[0]:
Quando ci si trova a rifare una macchina con relativo storage connesso potrebbe tornare utile. Ad esempio con Veritas Volume Manager è fondamentale labellizare correttamente il disco per poter utilizzare un formato in particolare durante la sua inizializzazione.
Da ricordare che la EFI label è il default che viene usato per dischi da 1 Terabyte in su.
Da ricordare anche che dischi con label EFI non sono compatibili in Diskgroups vxvm CDS, Cross-Platform Data Sharing, che è il formato che li rende importabili su qualsiasi piattaforma e OS per cui è disponibile VxVM.
# format -e
format> label
[0] SMI Label
[1] EFI Label
Specify Label type[0]:
Quando ci si trova a rifare una macchina con relativo storage connesso potrebbe tornare utile. Ad esempio con Veritas Volume Manager è fondamentale labellizare correttamente il disco per poter utilizzare un formato in particolare durante la sua inizializzazione.
Da ricordare che la EFI label è il default che viene usato per dischi da 1 Terabyte in su.
Da ricordare anche che dischi con label EFI non sono compatibili in Diskgroups vxvm CDS, Cross-Platform Data Sharing, che è il formato che li rende importabili su qualsiasi piattaforma e OS per cui è disponibile VxVM.
martedì 14 ottobre 2008
Hp-ux Fiber Channel Multipathing e StorageTek 6540
Ormai da tempo ho la possibilità di lavorare sul 6540, uno degli storage Midrange commercializzati da Sun. Il 6540 è il gemello del DS4800 di IBM, entrambi disegnati da Engenio, proprietà di LSI.
Ha due controllers con 4 porte 4 Gbit ciascuno. Con sistemi Sun SPARC e x64 il multipathing per lo spread e il failover del traffico viene gestito dallo Storagetek Traffic Manager, anche noto come MPXIO, disponibile in bundle su Solaris10 e scaricabile come pacchetto opzionale per le versioni precedenti.
Questo software è disponibile inoltre per Windows e Hp-Ux, tra gli altri, comunque a pagamento.
Hp-uX 11.31 ha un sistema di gestione del carico del traffico SAN nativo; non essendo disponibile il gestore Sun per questi sistemi abbiamo deciso di "give it a try".
Creare una LUN sul 6540 da mappare a un host Rx Integrity dotato di due HBA FC 4Gbit HP AB378-60101, al secolo QLogic ISP24xx, è procedura che segue parametri standard, se si eccettua che va selezionato "Hp-uX" come opzione Driver di Gestione SAN/Sistema Operativo. Naturalmente, sull'host non verrà presentato un singolo device logico virtuale come con mpxio, ma anzi, ben quattro path logici.
Quindi, se per una LUN lato host, su Solaris abbiamo qualcosa tipo:
c2 -> controller fisico 1
c3 -> controller fisico 2
c4 -> controller virtuale (quello a cui si fa riferimento nell'usare il volume)
Su Hp-uX con multipathing nativo avremo:
c2 -> controller fisico 1 controller A
c4 -> controller fisico 1 controller B
c6 -> controller fisico 2 controller A
c8 -> controller fisico 2 controller B
Comodo, vero?
I parametri di default lato host, in questo caso, non vanno bene. Le luns risultano pressochè inutilizzabili. L'algoritmo di bilanciamento di default è round-robin, ma l'implementazione pare incompatibile con l'array in questione, facendo risultare la user experience orribile; a quanto pare il problema sarebbe un continuo ping pong nell'inizializzazione della comunicazione tra target e initiator, che rende instabile e funzionante a singhiozzo l'I/O.
Tramite scsi_mgr, è possibile impostare parecchi parametri, tra cui anche l'algoritmo di bilanciamento. Una soluzione provata è stata quella di impostare la politica di bilanciamento dell'host come "usa il path più scarico". Questo ha fatto migliorare sensibilmente l'usabilità, ma risulta in una ennesima "incomprensione" tra host e storage, e quest'ultimo genera un warning ogni volta che l'host cambia il path in uso, essendo in disaccordo sul cambio di controller; viene effettivamente forzato e lo vede come un possibile problema.
Il 6540 lavora con la logica del preferred controller. Alla creazione del volume, esso gli assegna un preferred, che sarà la controller che cercherà di usare come primaria. Usando MPXIO, il sistema è in grado di comunicare e "collaborare" con lo storage per permettergli di seguire la sua logica di funzionamento. Il Native MP di Hp-uX 11i v3 non è in grado di seguire e collaborare a questa gestione dinamica, o per lo meno, non si accorda con lo storage per il cambio di path. Questo significa guai.
La soluzione in questo caso è stata forzare questo comportamento con una gestione manuale, individuando lato host il path corrispondente al preferred scelto dal 6540 e settandolo su Hp-uX come tale, stessa cosa per il secondario. Questo pare aver dato una configurazione funzionante, le prestazioni sembrano ok e nessun warning viene più generato.
Dai test eseguiti, ovvero, un reboot e la disconnessione fisica della fibra, sembra essere tutto ok.
Ovviamente, a ogni nuova lun creata si ripropone il problema di mappare correttamente sull'host i path primario e secondario come li sceglie lo storage.
Sarebbe interessante sapere come si sono "aggiustati" altri amministratori e avere qualche informazione in più sulla cosa. Sarebbe anche interessante vedere l'implementazione di mpxio su hp-ux.
Ha due controllers con 4 porte 4 Gbit ciascuno. Con sistemi Sun SPARC e x64 il multipathing per lo spread e il failover del traffico viene gestito dallo Storagetek Traffic Manager, anche noto come MPXIO, disponibile in bundle su Solaris10 e scaricabile come pacchetto opzionale per le versioni precedenti.
Questo software è disponibile inoltre per Windows e Hp-Ux, tra gli altri, comunque a pagamento.
Hp-uX 11.31 ha un sistema di gestione del carico del traffico SAN nativo; non essendo disponibile il gestore Sun per questi sistemi abbiamo deciso di "give it a try".
Creare una LUN sul 6540 da mappare a un host Rx Integrity dotato di due HBA FC 4Gbit HP AB378-60101, al secolo QLogic ISP24xx, è procedura che segue parametri standard, se si eccettua che va selezionato "Hp-uX" come opzione Driver di Gestione SAN/Sistema Operativo. Naturalmente, sull'host non verrà presentato un singolo device logico virtuale come con mpxio, ma anzi, ben quattro path logici.
Quindi, se per una LUN lato host, su Solaris abbiamo qualcosa tipo:
c2 -> controller fisico 1
c3 -> controller fisico 2
c4 -> controller virtuale (quello a cui si fa riferimento nell'usare il volume)
Su Hp-uX con multipathing nativo avremo:
c2 -> controller fisico 1 controller A
c4 -> controller fisico 1 controller B
c6 -> controller fisico 2 controller A
c8 -> controller fisico 2 controller B
Comodo, vero?
I parametri di default lato host, in questo caso, non vanno bene. Le luns risultano pressochè inutilizzabili. L'algoritmo di bilanciamento di default è round-robin, ma l'implementazione pare incompatibile con l'array in questione, facendo risultare la user experience orribile; a quanto pare il problema sarebbe un continuo ping pong nell'inizializzazione della comunicazione tra target e initiator, che rende instabile e funzionante a singhiozzo l'I/O.
Tramite scsi_mgr, è possibile impostare parecchi parametri, tra cui anche l'algoritmo di bilanciamento. Una soluzione provata è stata quella di impostare la politica di bilanciamento dell'host come "usa il path più scarico". Questo ha fatto migliorare sensibilmente l'usabilità, ma risulta in una ennesima "incomprensione" tra host e storage, e quest'ultimo genera un warning ogni volta che l'host cambia il path in uso, essendo in disaccordo sul cambio di controller; viene effettivamente forzato e lo vede come un possibile problema.
Il 6540 lavora con la logica del preferred controller. Alla creazione del volume, esso gli assegna un preferred, che sarà la controller che cercherà di usare come primaria. Usando MPXIO, il sistema è in grado di comunicare e "collaborare" con lo storage per permettergli di seguire la sua logica di funzionamento. Il Native MP di Hp-uX 11i v3 non è in grado di seguire e collaborare a questa gestione dinamica, o per lo meno, non si accorda con lo storage per il cambio di path. Questo significa guai.
La soluzione in questo caso è stata forzare questo comportamento con una gestione manuale, individuando lato host il path corrispondente al preferred scelto dal 6540 e settandolo su Hp-uX come tale, stessa cosa per il secondario. Questo pare aver dato una configurazione funzionante, le prestazioni sembrano ok e nessun warning viene più generato.
Dai test eseguiti, ovvero, un reboot e la disconnessione fisica della fibra, sembra essere tutto ok.
Ovviamente, a ogni nuova lun creata si ripropone il problema di mappare correttamente sull'host i path primario e secondario come li sceglie lo storage.
Sarebbe interessante sapere come si sono "aggiustati" altri amministratori e avere qualche informazione in più sulla cosa. Sarebbe anche interessante vedere l'implementazione di mpxio su hp-ux.
UPDATE:In realtà sulla 11.31 esiste , il nuovo standard per la nomenclatura dei mass storage devices, che coesistendo col vecchio schema definito ora "legacy addressing", lo va a rimpiazzare e sarà l'unico metodo in una prossima release.
domenica 13 luglio 2008
Nuovi StorageTek JX00 e Simple-Thumper
Stavo dando un'occhiata a tre nuovi piccoli storage devices freschi di "forno", appeni usciti dalla fornace di idee di Sun. Cito:
"basta averne il coraggio!!"
Per fortuna la configurazione comprendente controllers intellgenti sono capaci di RAID hardware nei livelli 0, 1, 10, 1E, 5, 6, 50, 5EE, 60.
Il J4200 e J4400 sono fondamentalmente lo stesso storage, la differenza sta nella capacità e in una dotazione magari più spinta, dove il primo supporta fino a 48 dischi SAS, mentre il maggiore arriva a 192. Parlano di 72Gb/s di capacità di banda quando tutte e sei le porte SAS sono in uso
Ci vanno poco più di 3000 dollari per la configurazione più piccola: 1 J4200 con due dischi.
Come per tutti i nuovi prodotti, la gestione viene affidata alla CAM, che facilita il lavoro di amministrazione ai clienti che non vogliono pagare personale specializzato, e rendono tristi i sysadmin più hard-core che rimpiangono le gioie di interfacciarsi e lavorare sui T3, 3510 e chi più ne ha più ne metta.
Ma ora arriviamo al pezzo che più mi ha visto interessato e più mi ha incuriosito: il J4500!
Eccolo, chi riconoscete da questa foto? E' thumper, il ciccione X4500 con cpu Amd e una bella spatafiata di dischi SATA da 3emezzo!! Anche lui generato per essere una vittima di ZFS, in uno dei primi tentativi di rifilarci il "Filesystem più fico e con più bits del mondo", magari addirittura spalmato su dischi in macchine di produzione :)
E infatti si tratta di Thumper, stesso chassis, ma niente cpu AMD e relativa dotazione, niente Solaris, e al suo posto una non ben precisata controller, 4 porte SAS da 3Gb/s, supporto per dischi SATA da 1 Tera e possibilita di espansione a 4 unità massime per un totale di 192 dischi e altrettanti Terabytes.
Per il raid HW i livelli sono gli stessi supportati dal J4400.
Nella lista dei servers supportati manca l'X4500, mi chiedo perchè.
Comunque è interessante questo prodotto, che sfrutta la peculiarità di storage server dell'X4500, amputato della presenza di Solaris per quei clienti che non necessitano della flessibilità che questo da, e delegando l'amministrazione alla CAM che sicuramente ne semplifica la gestione laddove manca il know-how, in più la possibilità di fondere la capacità di 4 di questi arrays assieme. Un Simple-Thumper?
Storage Expansion Arrays
The Sun Storage J4000 Family offers scalable, reliable storage, breakthrough economics, and heterogeneous support across Solaris, Windows, and Linux platforms.
Così sono definiti. In pratica, tradotto, si tratta di tre arrays, e naturalmente per il software RAID viene menzionato Zfs, per quanto riguarda le soluzioni basate su Solaris (e perchè no Mac OS X e FreeBSD, che ne hanno anche loro una implementazione) ... ZFS. Avrebbero potuto aggiungere solo più ..."basta averne il coraggio!!"
Per fortuna la configurazione comprendente controllers intellgenti sono capaci di RAID hardware nei livelli 0, 1, 10, 1E, 5, 6, 50, 5EE, 60.
Il J4200 e J4400 sono fondamentalmente lo stesso storage, la differenza sta nella capacità e in una dotazione magari più spinta, dove il primo supporta fino a 48 dischi SAS, mentre il maggiore arriva a 192. Parlano di 72Gb/s di capacità di banda quando tutte e sei le porte SAS sono in uso
Ci vanno poco più di 3000 dollari per la configurazione più piccola: 1 J4200 con due dischi.
Come per tutti i nuovi prodotti, la gestione viene affidata alla CAM, che facilita il lavoro di amministrazione ai clienti che non vogliono pagare personale specializzato, e rendono tristi i sysadmin più hard-core che rimpiangono le gioie di interfacciarsi e lavorare sui T3, 3510 e chi più ne ha più ne metta.
Ma ora arriviamo al pezzo che più mi ha visto interessato e più mi ha incuriosito: il J4500!
Eccolo, chi riconoscete da questa foto? E' thumper, il ciccione X4500 con cpu Amd e una bella spatafiata di dischi SATA da 3emezzo!! Anche lui generato per essere una vittima di ZFS, in uno dei primi tentativi di rifilarci il "Filesystem più fico e con più bits del mondo", magari addirittura spalmato su dischi in macchine di produzione :)
E infatti si tratta di Thumper, stesso chassis, ma niente cpu AMD e relativa dotazione, niente Solaris, e al suo posto una non ben precisata controller, 4 porte SAS da 3Gb/s, supporto per dischi SATA da 1 Tera e possibilita di espansione a 4 unità massime per un totale di 192 dischi e altrettanti Terabytes.
Per il raid HW i livelli sono gli stessi supportati dal J4400.
Nella lista dei servers supportati manca l'X4500, mi chiedo perchè.
Comunque è interessante questo prodotto, che sfrutta la peculiarità di storage server dell'X4500, amputato della presenza di Solaris per quei clienti che non necessitano della flessibilità che questo da, e delegando l'amministrazione alla CAM che sicuramente ne semplifica la gestione laddove manca il know-how, in più la possibilità di fondere la capacità di 4 di questi arrays assieme. Un Simple-Thumper?
venerdì 20 giugno 2008
Playing Linux Raid and Logical Volumes
Stasera si gioca col software Raid di linux.
Ho un Multipack di Sun, quello da 6 dischi scsi SCA (esiste il modello da 12) ... è pieno.
Ho Linux e in questo momento desidererei Solaris :)
Ma non demordo mica ... ho 6 dischi da 32 Gb e il bisogno di un volume per metterci "files artistici di futuristica visione commentanti un domani possibile", dicasi Star Trek; tanti ST!
Valuto che sarebbe bene un Raid5, meglio se ha spalmato sopra un volume e filesystem dinamici, per riorganizzare in seguito gli spazi.
Avendo a disposizione un Jbod e un HBA scsi senza RAID hardware, andrei per un Raid5 software con sopra quella che chiamerei una soft partition ... se solo avessi Solaris ... due comandi è il gioco è fatto.
SMETTILA!!
Il Software Raid di linux (mdraid) e lvm2 fanno al caso mio, quindi si comincia.
Su ogni disco fisico creo una partizione a colpi di:
# fdisk /dev/sdX
X va da a a a f.
Queste partizioni le darò in pasto a mdadm per creare il bimbo raid5, praticamente così:
169 Gb protetti, non male, speriamo anche funzioni come si deve;
devo dire che fin'ora, su macchine di produzione che mi sono capitate è
andato sempre tutto liscio.
Non rimane che scegliere un filesystem e crearcelo su, poi è pronto per essere montato.
Ho un Multipack di Sun, quello da 6 dischi scsi SCA (esiste il modello da 12) ... è pieno.
Ho Linux e in questo momento desidererei Solaris :)
Ma non demordo mica ... ho 6 dischi da 32 Gb e il bisogno di un volume per metterci "files artistici di futuristica visione commentanti un domani possibile", dicasi Star Trek; tanti ST!
Valuto che sarebbe bene un Raid5, meglio se ha spalmato sopra un volume e filesystem dinamici, per riorganizzare in seguito gli spazi.
Avendo a disposizione un Jbod e un HBA scsi senza RAID hardware, andrei per un Raid5 software con sopra quella che chiamerei una soft partition ... se solo avessi Solaris ... due comandi è il gioco è fatto.
SMETTILA!!
Il Software Raid di linux (mdraid) e lvm2 fanno al caso mio, quindi si comincia.
Su ogni disco fisico creo una partizione a colpi di:
# fdisk /dev/sdX
X va da a a a f.
Queste partizioni le darò in pasto a mdadm per creare il bimbo raid5, praticamente così:
#/sbin/mdadm --create --verbose /dev/md0 --level=5 \
--raid-devices=6 \
/dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1
mdadm: layout defaults to left-symmetric
mdadm: chunk size defaults to 64K
mdadm: size set to 35559744K
mdadm: array /dev/md0 started.
E questo è quanto, il disco logico raid5 è fatto; la palla passa a LVM2
Si tratta di tirare dentro md0 come PV, Phisical Volume, e creare un VG, Volume Group
che lo contiene ... esso avrà un nome, il mio si chiama multipack.
#pvcreate /dev/md0
Physical volume "/dev/md0" successfully created
#vgcreate multipack /dev/md0
Volume group "multipack" successfully created
Ok, infine, dando i Pe disponibili nel VG, visualizzabili col comando vgdisplay alla riga Free PE
si crea il Logical Volume:
lvcreate -l 43407 multipack -n DATA
Logical volume "DATA" created
Ora possiamo dire di avere il nostro bel volume, eccolo in tutto il suo splendore:
lvdisplay /dev/multipack/DATA
--- Logical volume ---
LV Name /dev/multipack/DATA
VG Name multipack
LV UUID Db0D3T-2xo0-uik3-hZdk-ykd4-61X0-Y1tUXY
LV Write Access read/write
LV Status available
# open 0
LV Size 169,56 GB
Current LE 43407
Segments 1
Allocation inherit
Read ahead sectors 0
Block device 253:0
169 Gb protetti, non male, speriamo anche funzioni come si deve;
devo dire che fin'ora, su macchine di produzione che mi sono capitate è
andato sempre tutto liscio.
Non rimane che scegliere un filesystem e crearcelo su, poi è pronto per essere montato.
venerdì 22 giugno 2007
SVM fa 0+1 o 1+0?
Capiamoci bene qualcosa!
Questo è un'arcano che prima o poi chiunque si pone.
Anche a me è successo tempo fa, che c'è di meglio di annotarlo sul mio blog?
Fortunatamente qualcuno ci spiega come funziona qui:
http://blogs.sun.com/andresblog/entry/raid_0_1_vs_raid
Il succo del discorso sta in:
So, does SVM do RAID 0+1 or RAID 1+0? The answer is, "Yes." So it gives you a choice between the two? The answer is "No."
So, in a nutshell, SVM provides a RAID 0+1 style administrative interface but effectively implements RAID 1+0 functionality. Administrators get the best of each type, the relatively simple administration of RAID 0+1 plus the greater resilience of RAID 1+0 in the case of multiple device failures.
Questo per i profani vuol dire che, se si hanno due concatenazioni di quattro dischi, messe in mirror con SDS/SVM, il metadevice sopravviverà alla "morte" di quattro dei dischi. Con un paio di spares siete in una cassaforte di ottima fattura... e al costo dei soli dischi, senza ricorrere a nessun accrocchio in hardware.
Cosa? C'è ZFS adesso? Si, ma questa è un'altra storia...
UPDATE
Mi ero ripromesso di linkare da qualche parte una pagina che tratta l'argomento di questo post, ed eccolo qui:
http://chrismiles.info/unix/sun/dsraid10.txt
Questo è un'arcano che prima o poi chiunque si pone.
Anche a me è successo tempo fa, che c'è di meglio di annotarlo sul mio blog?
Fortunatamente qualcuno ci spiega come funziona qui:
http://blogs.sun.com/andresblog/entry/raid_0_1_vs_raid
Il succo del discorso sta in:
So, does SVM do RAID 0+1 or RAID 1+0? The answer is, "Yes." So it gives you a choice between the two? The answer is "No."
So, in a nutshell, SVM provides a RAID 0+1 style administrative interface but effectively implements RAID 1+0 functionality. Administrators get the best of each type, the relatively simple administration of RAID 0+1 plus the greater resilience of RAID 1+0 in the case of multiple device failures.
Questo per i profani vuol dire che, se si hanno due concatenazioni di quattro dischi, messe in mirror con SDS/SVM, il metadevice sopravviverà alla "morte" di quattro dei dischi. Con un paio di spares siete in una cassaforte di ottima fattura... e al costo dei soli dischi, senza ricorrere a nessun accrocchio in hardware.
Cosa? C'è ZFS adesso? Si, ma questa è un'altra storia...
UPDATE
Mi ero ripromesso di linkare da qualche parte una pagina che tratta l'argomento di questo post, ed eccolo qui:
http://chrismiles.info/unix/sun/dsraid10.txt
DMP, AP, MPXIO e chi più ne ha...
Veritas Volume Manager è licenziato gratuitamente e in automatico sul glorioso Photon ( StorEdge A5200).
Si da il caso io ne abbia uno in produzione connesso tramite due SOCAL ad una antica Enterprise 3500 (robe di due UltraSPARC II 400mhz, per la serie una Ultra10 ce la fa prima e più silenziosamente).
Il mio predecessore ha quindi pensato di gestire i 22 dischi FC inseriti nel Photon tramite questo gestore di volumi, e con DMP, il gestore multipathing per failover e distribuzione del carico di Veritas, parte della Storage Foundation. Tutto su Solaris 9 09/05 ben patchato.
Dopo una lunga serie di problemi e fastidi che questa macchina è riuscita a darci nel tempo, è venuto all'attenzione di qualcuno il fatto che Vxvm era il gestore di volumi sul server, questo in contrasto con le "policy aziendali" che volevano che il compito fosse svolto da SDS.
A me il compito di ovviare all' "inconveniente" (che a mio giudizio così sconveniente non era, ma...). Iniziando col deincapsulare i dischi di boot e via via /var /app e tutto ciò che risiedeva sui 6 dischi interni al server... ho fatto il tutto durante un down programmato.
Mancava lo storage array. Decisi di rinviare e sperare che qualcuno dimenticasse.
Per convenzione, i backups del db (che è ciò che risiedeva nel dg datadg residente sul
Photon) sono compito dei DBA, quindi i filesystem su cui risiedono i datafiles, solitamente montati in /dati , io semplicemente, non li backuppo (e nemmeno gli darei un senso farlo, fosse anche con uno snapshot, vedi fssnap).
Morale della favola, saltano due dischi del raid5 del volume vxvm, e non c'è verso per cui riesca a recuperare il filesystem. Qui urge un filesystem nuovo e pulito e relativo backup dei DBAs! Ma ecco la notizia: per qualche motivo, i backups di questo db non sono mai stati fatti, anzi, si era deciso di non farli... come al solito senza dire nulla al sottoscritto!
Perfetto!
Si fa tutto da capo e da zero; viene pianificato il modo migliore per ricostruire il db. Per fortuna è possibile, costa tempo ma è già un miracolo che sia possibile.
Distruggo i volumi, e come richiesto, colgo l'occasione per rimuovere il Veritas e mettere sotto DiskSuite i dischi sul Photon.
Mi viene richiesto di ridondare ancora di più il filesystem dedicato al db, a costo dello spazio disponibile; opto per fare due Simple raid0 in mirror che SDS dovrebbe trattare come un raid1+0 (in accordo a un documento tecnico trovato tempo fa in rete e che appena ritrovo posterò).
Niente di meglio. Ci aggiungo due spare e via:
d100 -m d101 d102 1
d101 8 1 c2t1d0s0 \
1 c2t2d0s0 \
1 c2t3d0s0 \
1 c2t4d0s0 \
1 c2t7d0s0 \
1 c2t8d0s0 \
1 c2t9d0s0 \
1 c2t10d0s0 -h hsp001
d102 8 1 c2t16d0s0 \
1 c2t17d0s0 \
1 c2t18d0s0 \
1 c2t19d0s0 \
1 c2t20d0s0 \
1 c2t22d0s0 \
1 c2t24d0s0 \
1 c2t25d0s0 -h hsp002
Manca solo la gestione del multipathing.
Ora che ho tolto DMP (che tra l'altro, secondo l'assistenza era il possibile motivo di un'altro problema che mi assillava di tanto in tanto dove il loop mi andava OFFLINE e ONLINE causando un desync che magari c'entra anche qualcosa col disastro sul filesystem che sto rifacendo), opto per mpxio, il driver di Solaris dedicato al multipathing (integrato in Solaris10 , anche detto StorEdge Traffic Manager o simili e disponibile da installare per Solaris 9.
Configuro tutto, ma niente; allora mi rileggo le note; tutto molto plausibile (il non funzionamento). Le SOCAL non sono supportate da questo driver. Devo ripiegare sul vecchio, buggato, triste Alternate Pathing (AP2.3).
eh no! nemmeno lui va, la versione di Solaris in uso (9), e la macchina in questione non ne permettono l'uso... mi rimane... un bel nulla!
Niente da fare.
Alla fine si opta per: nessun multipathing (giustificato dalla possibilità di avere resilienza, in quanto le prestazioni su questa macchina non sono un must), e "speriamo" che tenga, in attesa che arrivino i Blades che ospiteranno i servizi residenti su questa macchina.
La morale di questa storia è: leggi due volte le release notes, non fidarti del tecnico che al telefono ti dice che puoi mettere mpxio, e successivamente AP, perchè tanto nemmeno lui ha letto le Release Notes e sta dando le cose per scontato quasi quanto te.
Si da il caso io ne abbia uno in produzione connesso tramite due SOCAL ad una antica Enterprise 3500 (robe di due UltraSPARC II 400mhz, per la serie una Ultra10 ce la fa prima e più silenziosamente).
Il mio predecessore ha quindi pensato di gestire i 22 dischi FC inseriti nel Photon tramite questo gestore di volumi, e con DMP, il gestore multipathing per failover e distribuzione del carico di Veritas, parte della Storage Foundation. Tutto su Solaris 9 09/05 ben patchato.
Dopo una lunga serie di problemi e fastidi che questa macchina è riuscita a darci nel tempo, è venuto all'attenzione di qualcuno il fatto che Vxvm era il gestore di volumi sul server, questo in contrasto con le "policy aziendali" che volevano che il compito fosse svolto da SDS.
A me il compito di ovviare all' "inconveniente" (che a mio giudizio così sconveniente non era, ma...). Iniziando col deincapsulare i dischi di boot e via via /var /app e tutto ciò che risiedeva sui 6 dischi interni al server... ho fatto il tutto durante un down programmato.
Mancava lo storage array. Decisi di rinviare e sperare che qualcuno dimenticasse.
Per convenzione, i backups del db (che è ciò che risiedeva nel dg datadg residente sul
Photon) sono compito dei DBA, quindi i filesystem su cui risiedono i datafiles, solitamente montati in /dati , io semplicemente, non li backuppo (e nemmeno gli darei un senso farlo, fosse anche con uno snapshot, vedi fssnap).
Morale della favola, saltano due dischi del raid5 del volume vxvm, e non c'è verso per cui riesca a recuperare il filesystem. Qui urge un filesystem nuovo e pulito e relativo backup dei DBAs! Ma ecco la notizia: per qualche motivo, i backups di questo db non sono mai stati fatti, anzi, si era deciso di non farli... come al solito senza dire nulla al sottoscritto!
Perfetto!
Si fa tutto da capo e da zero; viene pianificato il modo migliore per ricostruire il db. Per fortuna è possibile, costa tempo ma è già un miracolo che sia possibile.
Distruggo i volumi, e come richiesto, colgo l'occasione per rimuovere il Veritas e mettere sotto DiskSuite i dischi sul Photon.
Mi viene richiesto di ridondare ancora di più il filesystem dedicato al db, a costo dello spazio disponibile; opto per fare due Simple raid0 in mirror che SDS dovrebbe trattare come un raid1+0 (in accordo a un documento tecnico trovato tempo fa in rete e che appena ritrovo posterò).
Niente di meglio. Ci aggiungo due spare e via:
d100 -m d101 d102 1
d101 8 1 c2t1d0s0 \
1 c2t2d0s0 \
1 c2t3d0s0 \
1 c2t4d0s0 \
1 c2t7d0s0 \
1 c2t8d0s0 \
1 c2t9d0s0 \
1 c2t10d0s0 -h hsp001
d102 8 1 c2t16d0s0 \
1 c2t17d0s0 \
1 c2t18d0s0 \
1 c2t19d0s0 \
1 c2t20d0s0 \
1 c2t22d0s0 \
1 c2t24d0s0 \
1 c2t25d0s0 -h hsp002
Manca solo la gestione del multipathing.
Ora che ho tolto DMP (che tra l'altro, secondo l'assistenza era il possibile motivo di un'altro problema che mi assillava di tanto in tanto dove il loop mi andava OFFLINE e ONLINE causando un desync che magari c'entra anche qualcosa col disastro sul filesystem che sto rifacendo), opto per mpxio, il driver di Solaris dedicato al multipathing (integrato in Solaris10 , anche detto StorEdge Traffic Manager o simili e disponibile da installare per Solaris 9.
Configuro tutto, ma niente; allora mi rileggo le note; tutto molto plausibile (il non funzionamento). Le SOCAL non sono supportate da questo driver. Devo ripiegare sul vecchio, buggato, triste Alternate Pathing (AP2.3).
eh no! nemmeno lui va, la versione di Solaris in uso (9), e la macchina in questione non ne permettono l'uso... mi rimane... un bel nulla!
Niente da fare.
Alla fine si opta per: nessun multipathing (giustificato dalla possibilità di avere resilienza, in quanto le prestazioni su questa macchina non sono un must), e "speriamo" che tenga, in attesa che arrivino i Blades che ospiteranno i servizi residenti su questa macchina.
La morale di questa storia è: leggi due volte le release notes, non fidarti del tecnico che al telefono ti dice che puoi mettere mpxio, e successivamente AP, perchè tanto nemmeno lui ha letto le Release Notes e sta dando le cose per scontato quasi quanto te.
Iscriviti a:
Post (Atom)
Visite
