Questo capitolo contiene informazioni aggiornate relative all'uso dell'ambiente operativo Solaris per i sistemi Sun Fire 6800/4810/4800/3800.
Questa sezione fornisce informazioni sull'uso dell'ambiente operativo Solaris.
Il comando prtdiag è uno dei comandi dell'ambiente operativo Solaris che consentono di visualizzare i parametri di configurazione del sistema. Le informazioni fornite su questo comando nel documento Guida alle piattaforme hardware Sun non sono esatte per la versione corrente del sistema operativo. Attenersi quindi alle informazioni indicate a seguire.
Il comando prtdiag (1M) dell'ambiente operativo Solaris visualizza le informazioni seguenti sul dominio del sistema Sun Fire 6800/4810/4800/3800 in uso:
Configurazione
Diagnostica
Quantità totale di memoria (simile al comando prtconf)
La funzione di riconfigurazione dinamica (Dynamic reconfiguration, DR) è supportata per Solaris 8 2/02. Queste note contengono le informazioni più recenti sulle funzionalità di riconfigurazione dinamica (DR) per i sistemi Sun Fire 6800/4810/4800/3800 contemporanee a questa release.
Per informazioni sul firmware del controller di sistema che contiene la funzionalità DR, consultare il documento Sun Fire 6800/4810/4800/3800 Systems Software Release Notes incluso nella release 5.12.6 del firmware. Questo firmware e la relativa documentazione sono inclusi nella patch SunSolve 112127-02, disponibile sul sito Web di SunSolve (http://sunsolve.Sun.com).
Queste note sulla versione per la riconfigurazione dinamica (DR) sui sistemi Sun Fire 6800, 4810, 4800 e 3800 trattano gli argomenti seguenti:
Il comando cfgadm permette di visualizzare informazioni specifiche relative al supporto della funzione DR sui sistemi 6800/4810/4800/3800. Le schede di sistema sono indicate come classe "sbd." Le schede compactPCI (cPCI) sono indicate come classe "pci." Gli utenti della funzione DR attraverso l'interfaccia cfgadm visualizzano anche altre classi DR.
Per ulteriori informazioni sui problemi specifici di DR nei vari sistemi, vedere "Errori noti".
Per visualizzare le classi associate ai punti di collegamento, eseguire il comando seguente come superutente:
# cfgadm -s "cols=ap_id:class" |
Per elencare tali punti è possibile utilizzare anche il comando cfgadm con l'opzione -a. Per determinare la classe di un punto specifico, aggiungerlo come argomento al comando sopracitato.
Il software seguente supporta la funzione DR su un sistema Sun Fire: versione 8 2/02 dell'ambiente operativo Solaris e versione 5.12.6 del firmware di sistema.
Inoltre, è possibile optare per l'installazione di Sun Management Center (SunMC). Per istruzioni complete, vedere il documento Sun Management Center 3.0: Supplemento per sistemi Sun Fire 6800, 4810, 4800 e 3800.
È possibile eseguire l'aggiornamento del firmware dei sistemi Sun Fire tramite una connessione FTP o HTTP da un server FTP o HTTP dove è memorizzata l'immagine del firmware. Per ulteriori informazioni, vedere il documento Sun Fire 6800/4810/4800/3800 Systems Platform Administration Manual.
Ulteriori informazioni sull'installazione della patch del firmware sono disponibili nei file README e Install.info forniti con la patch.
Non aggiornare il firmware del controller di sistema senza aggiornare anche il firmware di tutte le schede CPU/memoria e gruppi I/O. Se infatti il firmware di schede CPU/memoria e gruppi I/O differisce da quello del controller di sistema, può non essere possibile effettuare il boot ai domini.
Impostare il server FTP o HTTP.
Per ulteriori informazioni, vedere l'appendice B del documento Sun Fire 6800/4810 /4800/3800 Systems Platform Administration Manual (numero di parte 805-7373-13).
Scaricare il firmware 5.12.6.
Questo firmware e la relativa documentazione sono inclusi nella patch SunSolve 112127-02, disponibile sul sito Web di SunSolve all'indirizzo:
http://sunsolve.Sun.COM/pub-cgi/show.pl?target=patches/patch-access
Copiare la patch sul server FTP o HTTP utilizzando un comando come il seguente:
# cp /patch_location/* /export/ftp/pub/5.12.6 |
Collegarsi alla console del controller di sistema (porta seriale) per monitorare il sistema quando si aggiorna il firmware (Punto 6).
Il prompt per il controller di sistema è il seguente:
nomehostsc:SC> |
Arrestare tutti i domini con l'arresto dell'ambiente operativo Solaris.
L'interruttore a chiave rimane nella posizione on in tali domini.
In ogni dominio arrestato con la procedura di cui al punto 5, impostare la posizione dell'interruttore a chiave su standby:
nomehostsc:A> setkeyswitch standby |
Verificare che tutte le schede CPU/memoria e i gruppi I/O siano alimentati eseguendo il comando showboards sul controller di sistema nella shell della piattaforma:
nomehostsc:SC> showboards |
Se alcune schede CPU/memoria o gruppi I/O non sono alimentati, utilizzare il comando poweron sul controller nella shell della piattaforma per alimentare tali componenti:
nomehostsc:SC> poweron nomi_componenti |
Aggiornare il firmware utilizzando il comando flashupdate sul controller di sistema nella shell della piattaforma.
Non spegnere il sistema o resettarlo mentre si esegue questo punto.
Utilizzare la sintassi del comando appropriata al protocollo URL:
nomehostsc:SC> flashupdate -f URL all |
Il comando flashupdate esegue il reboot del controller di sistema e aggiorna le schede CPU/memoria e gruppi I/O, scapp e RTOS.
Quando si esegue scapp 5.12.5 o superiore e RTOS 18 o superiore, la procedura di upgrade aggiorna scapp e RTOS solo quando l'immagine da installare è diversa dall'immagine attualmente installata.
Una volta eseguito correttamente il reboot del controller, collegarsi a ciascuna console di dominio e spegnere tutte le schede CPU/memoria e gruppi I/O impostando la posizione dell'interruttore a chiave su off:
nomehostsc:A> setkeyswitch off |
Verificare che tutte le schede CPU/memoria e i gruppi I/O siano spenti eseguendo il comando showboards sul controller di sistema nella shell della piattaforma:
nomehostsc:SC> showboards |
Se alcune schede CPU/memoria o gruppi I/O non sono spenti, utilizzare il comando poweroff sul controller nella shell della piattaforma per spegnere tali componenti:
nomehostsc:SC> poweroff nomi_componenti |
Attivare ciascun dominio impostando la posizione dell'interruttore a chiave su on:
nomehostsc:A> setkeyswitch on |
Una volta attivati tutti i domini, aggiornare il backup della configurazione del controller con il comando dumpconfig:
nomehostsc:SC> dumpconfig -f URL |
dove URL specifica il protocollo ftp.
Questa sezione contiene informazioni sui limiti noti della funzione DR sui sistemi Sun Fire 6800, 4810, 4800 e 3800.
Se si aggiunge una scheda di sistema a un dominio senza utilizzare le procedure DR, come con l'esecuzione del comando addboard dell'interfaccia dalla linea di comando (CLI) sul controller di sistema (SC), occorre eseguire il comando setkeyswitch off e quindi il comando setkeyswitch on per attivare la scheda nel sistema.
Questa release del software DR non supporta Sun StorEdge Traffic Manager.
Prima di eseguire qualsiasi operazione di DR su una scheda di I/O (IBx), immettere il comando seguente per arrestare il daemon vold:
# sh /etc/init.d/volmgt stop |
Una volta completata correttamente l'operazione di DR, immettere il comando seguente per riavviare il daemon vold:
# sh /etc/init.d/volmgt start |
Sui sistemi Sun Fire 6800, 4810, 4800 e 3800, la funzione DR non supporta i driver HIPPI/P, SAI/P (errore 4466378) e SunHSI/P (errore 4496362).
È necessario eseguire il comando devfsadm(1M) per visualizzare le modifiche apportate, in particolare per quanto riguarda quelle da PCI a cPCI.
Non effettuare il reboot né il reset del controller di sistema (SC) durante le operazioni di DR. Inoltre, non eseguire un aggiornamento flash, che richiede il reboot al completamento.
È possibile deconfigurare un gruppo I/O CompactPCI (cPCI) solo se tutte le card nella scheda sono in stato di deconfigurazione. Se qualsiasi card cPCI è occupata (come nel caso di un'interfaccia attivata (plumb) o di un disco attivato), l'operazione di deconfigurazione della scheda non riesce con lo stato "busy". Tutte le card cPCI dovrebbero essere deconfigurate prima di procedere alla deconfigurazione del gruppo I/O cPCI.
Quando un disco multipath è collegato a due card cPCI, è possibile visualizzare l'attività del disco sulle schede quando non è attesa alcuna attività. Per questo motivo, accertarsi che non vi sia attività sul lato locale della risorsa. Questa condizione ha maggiori probabilità di verificarsi quando si cerca di eseguire operazioni di DR su una card cPCI che mostra uno stato di occupato, persino quando non vi è attività sul lato locale della risorsa. Può essere richiesto un successivo tentativo di DR.
Quando l'utente elenca i punti di collegamento utilizzando il comando cfgadm(1M) con l'opzione -a, gli slot cPCI e i bus PCI sono tutti elencati come punti di collegamento. Il comando cfgadm -a visualizza un punto di collegamento per un bus PCI come N0.IB8::pci0. Vi sono quattro di tali punti per tale scheda cPCI. L'utente non dovrebbe eseguire operazioni di DR su di essi, né sul punto di collegamento sghsc (che il comando cfgadm -a visualizza come N0.IB8::sghsc4), perché la funzione di riconfigurazione dinamica non viene effettivamente eseguita e alcune risorse interne vengono rimosse. Tuttavia, questa operazione non produce alcun danno.
Per far sì che configurazione dinamica funzioni correttamente con le card cPCI, i livelli su tutte le schede cPCI inserite al momento del boot di Solaris devono essere pienamente impegnati.
Recuperare nome del gruppo, indirizzo test e indice interfaccia digitando il comando seguente.
# ifconfig interfaccia |
Per esempio, ifconfig hme0
Utilizzare il comando if_mpadm(1M) come segue:
# if_mpadm -d interfaccia |
Questa operazione porta l'interfaccia offline e causa il failover degli indirizzi con failover su un'altra interfaccia attiva del gruppo. Se l'interfaccia è già in stato di errore ("fail"), questa procedura esegue una semplice marcatura e garantisce che l'interfaccia sia offline.
(Opzionale) Disattivazione (unplumb) dell'interfaccia.
Questa procedura è richiesta solo se si desidera utilizzare la riconfigurazione dinamica per riconfigurare automaticamente l'interfaccia in un secondo momento.
Rimuovere l'interfaccia fisica.
Fare riferimento alla pagina man cfgadm(1M) e al documento Sun Fire 6800, 4810, 4800 and 3800 Systems Dynamic Reconfiguration User Guide per ulteriori informazioni.
Collegare l'interfaccia fisica.
Fare riferimento alla pagina man cfgadm(1M) e al documento Sun Fire 6800, 4810, 4800 and 3800 Systems Dynamic Reconfiguration User Guide per ulteriori informazioni.
Una volta collegata, l'interfaccia fisica viene automaticamente configurata utilizzando le impostazioni del file di configurazione hostname (/etc/hostname.interfaccia, dove interfaccia è un valore quale hme1 o qfe2).
Ciò attiva il daemon in.mpathd per riprendere le operazioni di sondaggio e rilevare le riparazioni. Di conseguenza, in.mpathd causa il failback degli indirizzi IP originali a questa interfaccia. L'interfaccia non dovrebbe ora essere online e pronta all'uso con IPMP.
Se l'interfaccia non è stata disattivata (unplumb) e portata in stato OFFLINE prima di un'operazione di scollegamento precedente, l'operazione di collegamento qui descritta non produce la sua configurazione automatica. Per riportare l'interfaccia allo stato ONLINE ed eseguire il failback del suo indirizzo IP una volta completato il collegamento fisico, immettere il comando seguente: if_mpadm -r interfaccia
Questa sezione fornisce informazioni sulla memoria permanente e descrive come portare il sistema operativo in stato di quiescenza per la deconfigurazione di una scheda dotata di memoria permanente.
Il sistema più rapido per determinare se una scheda dispone di memoria permanente è quello di eseguire il comando seguente come superutente:
# cfgadm -av | grep permanent |
Il sistema risponde con un output simile al seguente, che descrive la scheda di sistema 0 (zero):
N0.SB0::memory connected configured ok base address 0x0, 4194304 KBytes total, 668072 KBytes permanent |
La memoria permanente è dove risiedono il kernel di Solaris e i suoi dati. Il kernel non può essere rilasciato dalla memoria nello stesso modo in cui i processi utente residenti su altre schede rilasciano la memoria, mediante paging out al dispositivo di swap. Al contrario, per il rilascio della memoria, cfgadm utilizza la tecnica copia-rinomina.
La prima fase dell'operazione di copia-rinomina è quella di arrestare ogni attività della memoria sul sistema mettendo in pausa tutte le operazioni di I/O e le attività dei thread; questo stato è noto come quiescenza (quiescence). In questo stato, il sistema è "congelato" e non risponde agli eventi esterni quali i pacchetti di rete. La durata della quiescenza dipende da due fattori: il numero di dispositivi di I/O e di thread da arrestare e la quantità di memoria da copiare. Generalmente, il numero di dispositivi di I/O determina il tempo di quiescenza richiesto, perché i dispositivi di I/O devono essere portati in pausa e riportati in attività. In genere, lo stato di quiescenza dura più di due minuti.
Poiché la quiescenza non produce un impatto rilevabile, cfgadm richiede conferma all'utente prima di portare il sistema in stato di quiescenza. Se si immette:
# cfgadm -c unconfigure N0.SB0 |
Il sistema risponde con il prompt per la conferma:
System may be temporarily suspended, proceed (yes/no)? |
Se si utilzza SunMC per eseguire l'operazione di DR, il prompt viene visualizzato in una finestra a comparsa.
Immettere yes per confermare che l'impatto dello stato di quiescenza è accettabile e per procedere.
Questa sezione contiene una breve descrizione e i numeri di ID Sun degli errori più importanti rilevati durante il testing del software DR. L'elenco a seguire non è da considerarsi esaustivo.
Descrizione: se un sistema sta eseguendo il processo cryptorand del package SUNWski, una deconfigurazione della memoria, come parte della disconnessione di una scheda CPU/memoria (SB), fa sì che cryptorand si chiuda con i messaggi registrati in /var/adm/messages. Questa azione impedisce ai servizi di assegnazione di numeri generati casualmente di rendere sicuri i sottosistemi, pertanto non si dovrebbe deconfigurare la memoria presente quando cryptorand è avviato.
Il processo cryptorand fornisce un numero generato casualmente per /dev/random. Una volta avviato cryptorand, il tempo necessario prima che /dev/random diventi disponibile dipende dalla quantità di memoria del sistema. Possono essere richiesti circa due minuti per ogni GB di memoria. Le applicazioni che utilizzano /dev/random per ricavare numeri casuali possono essere interessate da un blocco temporaneo. Non è necessario riavviare cryptorand se viene aggiunta una scheda CPU/memoria a un dominio.
Soluzione: se viene rimossa dal dominio una scheda CPU/memoria, riavviare cryptorand immettendo il comando seguente come superutente:
# sh /etc/init.d/cryptorand start |
Descrizione: si può verificare un errore di tipo panic quando una scheda di sistema contenente CPU viene rimossa dal sistema mentre è in uso Solaris Bandwidth Manager (SBM).
Soluzione: non installare SBM sui sistemi che saranno utilizzati per le prove di DR e non eseguire le operazioni di DR della scheda di sistema con CPU su sistemi su cui è installato SBM.
Descrizione: un'operazione di configurazione di DR si blocca con una scheda IBx (I/O) dopo alcune iterazioni riuscite. Questa situazione si verifica quando l'operazione di DR viene eseguita simultaneamente al daemon DMP che implementa la politica check_all con un intervallo di tempo.
Soluzione: per evitare lo stallo tra il daemon DMP e la riconfigurazione dinamica della scheda di sistema, immettere il comando seguente prima di eseguire le operazioni di DR. Questo comando arresta e riavvia il daemon DMP.
# /usr/sbin/vxdmpadm stop restore |
Descrizione: quando un controller SCSI è configurato ma non occupato, non può essere scollegato utilizzando il comando di DR cfgadm(1M).
Soluzione: nessuna.
Descrizione: quando un client in multithreading della libreria cfgadm emette richieste sbd simultanee, il sistema può bloccarsi.
Soluzione: nessuna. Attualmente non vi sono applicazioni che implementino l'uso in multithreading della libreria cfgadm.
Descrizione: quando si verificano simultaneamente più operazioni di DR, o quando psradm viene eseguito contemporaneamente a un'operazione di DR, il sistema può bloccarsi a causa di un errore di abbraccio mortale mutex.
Soluzione: eseguire le operazioni di DR in serie (ovvero, un'operazione di DR per volta) e lasciare che ognuna di esse venga completata correttamente prima di eseguire psradm, oppure prima di iniziare un'altra operazione di DR.
Descrizione: talvolta viene generato un messaggio di errore del bus di console durante le operazioni get di SNMP sull'oggetto cpuModDescr. Questa condizione non si verifica frequentemente e solo quando SunMC sta monitorando un sistema. Quando si verifica il messaggio, a SunMC viene restituito unknown come valore dell'oggetto cpuModDescr.
Soluzione: l'unica soluzione consiste nel non utilizzare SunMC. Tuttavia, il messaggio non è pericoloso e il problema si verifica raramente, quindi si può semplicemente ignorarlo. L'unico rischio è che la GUI di SunMC può occasionalmente visualizzare il valore errato per cpuModDescr.
Può presentarsi un errore panic del sistema Sun Fire se una o più delle schede CPU sono messe in pausa sync durante un'operazione di DR. La pausa sync è richiesta per collegare o scollegare le schede. Se vi sono interrupt mondo in sospeso e per qualsiasi motivo SC non è in grado di completare la pausa sync entro il limite send_mondo timeout di un secondo, il sistema produce l'errore panic.