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 storage. Mostra tutti i post
Visualizzazione post con etichetta storage. Mostra tutti i post
martedì 16 febbraio 2010
sabato 6 febbraio 2010
5 ore di Webcast: il futuro di Sun in Oracle
| Speaker | Webcast |
| Charles Phillips: Welcome and Oracle + Sun: Transforming the Industry |
|
| John Fowler: Hardware Strategy |
|
| Thomas Kurian: Software Strategy |
|
| Edward Screven: Operating Systems and Virtualization |
|
| Juergen Rottler: Customer Service and Support Strategy |
|
| Jeff Epstein: Operational Strategy |
|
| Larry Ellison: Oracle + Sun |
|
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
domenica 2 agosto 2009
Montare UFS in Linux
La tabella dei types da passare al comando mount in Linux per montare filesystems ufs
# mount -t ufs -o ufstype=sun /dev/sdb1 /mnt
- old : Old format of ufs, this is the default, read only. (Don’t forget to give the -r option.)
- 44bsd : For filesystems created by a BSD-like system like NetBSD,FreeBSD, and OpenBSD
- sun : For filesystems created by SunOS or Solaris on Sparc.
- sunx86 : For filesystems created by Solaris on x86.
- hp : For filesystems created by HP-UX, read-only.
- nextstep : For filesystems created by NeXTStep (read only).
- nextstep-cd : For NextStep CDROMs (block_size == 2048),
- openstep : For filesystems created by OpenStep (currently read only). The same filesystem type is also used by MacOSX
# mount -t ufs -o ufstype=sun /dev/sdb1 /mnt
venerdì 15 maggio 2009
Sul futuro ...
Mi chiedo cosa ne sarà dei prodotti open sponsorizzati da Sun e/o derivanti da ex-codice chiuso Sun. In teoria progetti come Opensolaris dovrebbero continuare a vivere e risplendere di luce propria; mi chiedo anche come saranno commercializzati i software Sun che non verranno "fatti fuori"; Oracle taglierà i ponti con l'open source, fermando ciò che sta venendo rilasciato o che avrebbe dovuto essere rilasciato in futuro? I software free-to-use, in primis Solaris, continueranno a essere tali?
Sul versante tecnologie hardware, a detta di Ellison (vedi il penultimo post, escluso quello che stai leggendoi, su questo blog), SPARC e storage (arrays e tape libraries) andranno avanti, non si sa se nel modo attuale, però. Sicuramente usciranno prodotti nuovi, appliances all-inclusive, frutto e motivo primo dell'acquisto delle tecnologie possedute da Sun Microsystems.
Immagino sistemi integrati, dove la macchina, magari dotata di storage interno (cosa che già succede con prodotti Sun come l'x4600), ospita una versione customizzata di Solaris, pronta e ottimizzata per farci girare i prodotti software più in voga, già installati e pronti all'uso. Quello che già Oracle fa con Exabyte, che Hp e IBM già propongono da tempo, e quello che, se ho ben capito sta preparandosi a fare anche Cisco.
Sul versante tecnologie hardware, a detta di Ellison (vedi il penultimo post, escluso quello che stai leggendoi, su questo blog), SPARC e storage (arrays e tape libraries) andranno avanti, non si sa se nel modo attuale, però. Sicuramente usciranno prodotti nuovi, appliances all-inclusive, frutto e motivo primo dell'acquisto delle tecnologie possedute da Sun Microsystems.
Immagino sistemi integrati, dove la macchina, magari dotata di storage interno (cosa che già succede con prodotti Sun come l'x4600), ospita una versione customizzata di Solaris, pronta e ottimizzata per farci girare i prodotti software più in voga, già installati e pronti all'uso. Quello che già Oracle fa con Exabyte, che Hp e IBM già propongono da tempo, e quello che, se ho ben capito sta preparandosi a fare anche Cisco.
lunedì 11 maggio 2009
Intervista a Ellison
Milkowski ha intercettato e postato su PlanetSolaris il link a unPDF contenente un'intervista a Ellison di Oracle.
Si parla chiaramente del fatto che SPARC e Solaris continueranno a vivere. In che forma, probabilmente diversa dall'attuale (a me sa di progetto di sfornare appliances all-inclusive per il software Oracle), non ci è dato di sapere ancora di preciso.
La domanda che avrei fatto io è: "Ma tra 1 anno, potrò acquistare il mio Sun Cluster su 25K (o equivalente) come posso fare oggi?" - Sarebbe certamente la risposta più interessante da sentire da Oracle. Anche il settore storage dovrebbe continuare a esistere.
Si parla chiaramente del fatto che SPARC e Solaris continueranno a vivere. In che forma, probabilmente diversa dall'attuale (a me sa di progetto di sfornare appliances all-inclusive per il software Oracle), non ci è dato di sapere ancora di preciso.
La domanda che avrei fatto io è: "Ma tra 1 anno, potrò acquistare il mio Sun Cluster su 25K (o equivalente) come posso fare oggi?" - Sarebbe certamente la risposta più interessante da sentire da Oracle. Anche il settore storage dovrebbe continuare a esistere.
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.
lunedì 16 febbraio 2009
ZFS Vs, Data Rot
Quite simply, data rot is the result of tiny changes in the magnetic particles that make up the media in hard disks. The effect this has on your data is random but predictable: data loss.Ho scoperto questo interessante articolo su BigAdmin, che, oltre ad avermi illuminato su questa interessante anomalia dei dischi fissi, parla di come il più rivoluzionario filesystem degli ultimi anni, ZFS, (che non è mio "amico", ma che un giorno lo diventerà) a detta dell'autore, risponde a questo inconveniente.
Si può leggere qui
giovedì 11 dicembre 2008
Informazioni su StorageTek 6540 e Nagios Plugin
Ho trovato questa pagina, che dovrebbe essere un documento operativo sul 6540 di StorageTek; è in norvegese, ma potete incollare il seguente link qui e avere una grossolana traduzione in italico (o altro se si preferisce):
il link a un plugin per Nagios per la CAM e la serie 6xxx degli array Sun Storagetek.
Praticamente, questo plugin è uno script perl che va a guardare nella directory dove la CAM mette gli allarmi (solitamente ogni allarme è custodito li sottoforma di file: un allarme - un file); non vedo indicato la directory degli allarmi, ma a memoria sta sotto /var/opt/SUNWsefms in una directory chiamata alarms o notifications (magari find può essere più preciso se gli chiedete).
Nello stesso sito anche altri plugin interessanti per il check di HBA scsi adaptec, Oracle health e MySQL performance, stato di servers HP Proliant ecc ecc
Insomma, una letta questa pagina, la merita.
http://hpc.uio.no/index.php/Norstore_operational_documentCi sono esempi dell'uso della riga di comando e anche una chicca:
il link a un plugin per Nagios per la CAM e la serie 6xxx degli array Sun Storagetek.
Praticamente, questo plugin è uno script perl che va a guardare nella directory dove la CAM mette gli allarmi (solitamente ogni allarme è custodito li sottoforma di file: un allarme - un file); non vedo indicato la directory degli allarmi, ma a memoria sta sotto /var/opt/SUNWsefms in una directory chiamata alarms o notifications (magari find può essere più preciso se gli chiedete).
Nello stesso sito anche altri plugin interessanti per il check di HBA scsi adaptec, Oracle health e MySQL performance, stato di servers HP Proliant ecc ecc
Insomma, una letta questa pagina, la merita.
lunedì 27 ottobre 2008
Maledetto initiator ID aka "Scsi initiator ID is now 6"!!
Rifacendo un cluster con un vecchio JBOD scsi come shared storage, sono incorso in un conflitto di target ID nella catena scsi tra lo storage sharato e i due nodi.
In questo tipo di configurazione, uno dei due nodi va configurato ad hoc, agendo su alcuni parametri in OBP, in modo da evitare appunto conflitti.
Questo passaggio l'ho fatto già diverse volte, non tantissime, visto che per lo più capita di lavorare su devices fiber-channel, ma abbastanza da essere routine.
Si tratta di agire sulla variabile scsi-initiator-id di un nodo, portando il valore dal default (7) a 6, e poi inserire uno script in nvramrc, abilitandone l'uso mettendo a true use-nvramrc?. Questo in spiccioli aggira il conflitto tra gli HBA dei due nodi dandogli ID diversi, e poi al caricamento di Solaris, risetta in modo trasparente l'ID. Fatto.
Booto. Parte. Uno sfacelo. Decine di errori con molto poco senso, che tutto dicono, tranne quello che è ovvio (vabbè, l'ho esagerata, il loro senso lo hanno).
C'è da dire, che avevo già installato Solaris10 via flar sui nodi, e anche Sun Cluster che era in installmode, in attesa che designassi una DID come quorum.
Dopo un pò di riavvii stressanti e di set-defaults di OBP e rifacimento dei settaggi di cui sopra, mi illumino. Booto un solo nodo, lo booto -xvsr e osservo:
manca la dichiarazione "Scsi initiator ID is now 6". Viene bypassato, il trucco non viene implementato.
Disabilito il parsing di nvramrc settando a false "use-nvramrc?".
Ribooto ... nulla.
STOP-A brutale! Spengo lo storage. Do un reset-all. Ribooto.
Lo vedo: "Scsi initiator ID is now 6" !!
Poweroff ... accendo il JBOD ... accendo il nodo ... boot -v
Pare andare. Accendo l'altro nodo ... TUTTO OK!!!
Riabilito use-nvramrc? . Riavvio i nodi, tutto va.
Morale della favola:
le modifiche vanno implementate a storage spento (magari prima di installare Solaris, ma non è mandatorio come ho letto in alcuni documenti sull'argomento).
Dopo le modifiche è bene dare un reset-all. Provare che la configurazione venga usata. Spegnere e riavviare a storage acceso. Avviare l'altro nodo per avere conferma.
In questo tipo di configurazione, uno dei due nodi va configurato ad hoc, agendo su alcuni parametri in OBP, in modo da evitare appunto conflitti.
Questo passaggio l'ho fatto già diverse volte, non tantissime, visto che per lo più capita di lavorare su devices fiber-channel, ma abbastanza da essere routine.
Si tratta di agire sulla variabile scsi-initiator-id di un nodo, portando il valore dal default (7) a 6, e poi inserire uno script in nvramrc, abilitandone l'uso mettendo a true use-nvramrc?. Questo in spiccioli aggira il conflitto tra gli HBA dei due nodi dandogli ID diversi, e poi al caricamento di Solaris, risetta in modo trasparente l'ID. Fatto.
Booto. Parte. Uno sfacelo. Decine di errori con molto poco senso, che tutto dicono, tranne quello che è ovvio (vabbè, l'ho esagerata, il loro senso lo hanno).
C'è da dire, che avevo già installato Solaris10 via flar sui nodi, e anche Sun Cluster che era in installmode, in attesa che designassi una DID come quorum.
Dopo un pò di riavvii stressanti e di set-defaults di OBP e rifacimento dei settaggi di cui sopra, mi illumino. Booto un solo nodo, lo booto -xvsr e osservo:
manca la dichiarazione "Scsi initiator ID is now 6". Viene bypassato, il trucco non viene implementato.
Disabilito il parsing di nvramrc settando a false "use-nvramrc?".
Ribooto ... nulla.
STOP-A brutale! Spengo lo storage. Do un reset-all. Ribooto.
Lo vedo: "Scsi initiator ID is now 6" !!
Poweroff ... accendo il JBOD ... accendo il nodo ... boot -v
Pare andare. Accendo l'altro nodo ... TUTTO OK!!!
Riabilito use-nvramrc? . Riavvio i nodi, tutto va.
Morale della favola:
le modifiche vanno implementate a storage spento (magari prima di installare Solaris, ma non è mandatorio come ho letto in alcuni documenti sull'argomento).
Dopo le modifiche è bene dare un reset-all. Provare che la configurazione venga usata. Spegnere e riavviare a storage acceso. Avviare l'altro nodo per avere conferma.
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.
Iscriviti a:
Post (Atom)
Visite
