|
|
Italia - Italiano | |
|
|
 |
|
Informazioni sulla release del software di amministrazione VSE versione A.03.00.00 > Capitolo 5 Informazioni sulla release specifiche dell'applicazione
Informazioni sulla release di Global Workload Manager |
|
|
È previsto che Global Workload Manager abbia il controllo completo delle CPU disponibili in un sistema mentre è messo in attività un dominio di risorse condivise. Tuttavia, in alcune occasioni sarà necessario eseguire delle modifiche manuali, come:
Se fosse necessario eseguire una di queste modifiche manuali, eseguire le operazioni seguenti:
Global Workload Manager A.03.00.00 non è compatibile con le versioni di HP Integrity VM precedenti alla versione A.02.00. Se si desidera amministrare le macchine virtuali con gWLM A.03.00.00, HP suggerisce di effettuare l'aggiornamento a HP Integrity Virtual Machines versione A.03.00.00 o successiva. Non eseguendo l'aggiornamento, potrebbero essere visualizzati messaggi come: Unable to deploy SRD nome_dominio: A VM encountered with no size oppure Unable to deploy SRD 'nome_dominio':guestCpuSetEntitlement (): hpvm_nonvm_cpu_set_entitlement (HPVM_NONVM, (100.000000,100.000000),FALSE) failed: (0,90) Se possibile, eseguire l'aggiornamento a HP Integrity VM versione A.03.00 o successiva. Nel caso non sia possibile eseguire l'aggiornamento dalla versione A.01.20 di HP Integrity Virtual Machines, sarà necessario installare nel proprio host di macchine virtuali l'agente software gWLM versione A.02.00.00. Se non fosse possibile eseguire l'aggiornamento da HP Integrity Virtual Machines versione A.02.00, installare l'agente gWLM versione A.02.50.00, oppure utilizzare gWLM A.03.00.00 solamente per la gestione delle macchine virtuali con diritti specificati in percentuale. (Cioè, non gestire le macchine virtuali con diritti specificati in cicli di CPU.) Per ottenere le versioni precedenti dell'agente gWLM e per l'assistenza con questa configurazione, contattare HP al seguente indirizzo e-mail: <gwlmfeedback@rsn.hp.com>. Non è possibile utilizzare contemporaneamente gWLM con PRM – Process Resource Manager – né con WLM – Workload Manager – per gestire il medesimo sistema. Il tentativo di fare ciò restituirà un messaggio che segnala la presenza di un blocco mantenuto dall'applicazione che sta effettivamente amministrando il sistema. In questa situazione, prima di utilizzare gWLM è necessario chiudere l'applicazione che mantiene il blocco. Con PRM, eseguire i comandi seguenti:
Con WLM, eseguire i comandi seguenti:
Per informazioni sulle limitazioni dell'utilizzo di gWLM con Global Instant Capacity, visitare il sito http://docs.hp.com/en/vse.html e cercare il libro bianco "Using Global Workload Manager 3.0 with Global Instant Capacity." Secondo le caratteristiche del carico di lavoro, gWLM è in grado di migrare rapidamente le risorse CPU. Questa frequente migrazione può potenzialmente, anche se molto raramente, produrre una condizione di conflitto, che provoca il blocco anomalo della partizione virtuale. Potrebbe inoltre provocare un panico, con uno o più dei seguenti messaggi: No Chosen CPU on the cell-cannot proceed with NB PDC. oppure PDC_PAT_EVENT_SET_MODE(2) call returned error L'aggiornamento a vPars A.03.04 risolve questo problema. Con le precedenti versioni di vPars, è possibile aggirare il problema nel modo seguente: assegnare – utilizzando l'assegnazione del percorso – almeno una CPU vincolata per cella ad almeno una partizione virtuale. (Può essere una partizione virtuale qualunque.) Ciò garantirà che non avvenga la riassegnazione nella migrazione di CPU. Ad esempio, se si hanno quattro celle (0, 1, 2, 3), ciascuna con quattro CPU (10, 11, 12, 13) e quattro partizioni virtuali (vpar1, vpar2, vpar3, vpar4), si dovrebbe assegnare 0/1x alla vpar1, 1/1x alla vpar2, 2/1x alla vpar3 e 3/1x alla vpar4, dove x è 0,1,2,3. Migrando una macchina virtuale da un host di macchine virtuali che fa parte di un dominio di risorse condivise, sarà necessario rimuovere la macchina virtuale da tale dominio prima di aggiungerla ad un dominio nel nuovo host di macchine virtuali. Rimuovere la macchina virtuale dal dominio di risorse condivise prima di eseguire la sua migrazione. Eseguendo la migrazione della macchina virtuale prima di rimuoverla dal dominio di risorse condivise può portare alle condizioni seguenti, secondo l'interfaccia utilizzata.
La versione A.03.00.00 di Global Workload Manager comprende le seguenti correzioni di errori: Comportamento precedente: Il file /etc/opt/gwlm/conf/gwlmcms.properties è sovrascritto eseguendo il comando vseinitconfig. Comportamento corrente: Il file /etc/opt/gwlm/conf/gwlmcms.properties non è più sovrascritto. Comportamento precedente: Global Workload Manager utilizza iCAP per amministrare le nPartition. Con iCAP B.08.00, i tentativi di gWLM di modificare le risorse iCAP non avranno successo se il sistema non ha un bilancio positivo di TiCAP. Comportamento corrente: Non è necessario un bilancio positivo di TiCAP. Comportamento precedente: In un dominio di risorse condivise che amministra partizioni virtuali annidate in una nPartition, potrebbero essere visualizzate informazioni sullo stato che indicano un avviso di attenzione importante nella schermata Shared Resource Domain. L'avviso indica che l'assegnazione di CPU è maggiore della dimensione del dominio di risorse condivise. Comportamento corrente: Ora è possibile amministrare un sottoinsieme delle partizioni virtuali in una nPartition senza la generazione di avvisi. Modificando un criterio personalizzato, scegliendo il pulsante OK il valore di Metric Response è impostato a Inverse. È possibile modificare il criterio usando l'interfaccia a riga dei comandi di gWLM nel modo seguente.
Se si sta utilizzando gWLM, disponendo di uno dei due tipi seguenti di domini di risorse condivise basati su partizioni e avendo effettuato l'aggiornamento degli agenti gWLM nelle partizioni, da gWLM A.01.x a gWLM A.03.00.00, non sarà possibile aggiungere al dominio di risorse condivise altre partizioni nello stesso complesso:
Per ripristinare il dominio di risorse condivise, utilizzare la procedura seguente nel server di amministrazione centrale:
Global Workload Manager è in grado di attivare TiCAP, se questo è necessario per soddisfare i criteri del dominio di risorse condivise. Per evitare il consumo non necessario di TiCAP, è necessario disporre di un numero sufficiente di CPU con licenze senza scadenza. Se il proprio dominio di risorse condivise è più grande di questo numero, per soddisfare le richieste del dominio di risorse condivise sarà consumata della capacità temporanea. Un carico di lavoro può essere gestito da gWLM in un solo dominio di risorse condivise in attività alla volta. Di conseguenza, se un carico di lavoro è associato direttamente con un pacchetto di Serviceguard – utilizzando la selezione nella finestra di dialogo Workload Definition – gWLM sarà in grado di gestirlo in uno solo degli host in cui può essere eseguito. Se una macchina virtuale è associata ad un pacchetto di Serviceguard, in ciascun host di macchine virtuali essa sarà rappresentata da un carico di lavoro distinto. In ogni caso, non sarà possibile gestire un singolo carico di lavoro quando segue il pacchetto Serviceguard associato. Ad carico di lavoro associato ad un pacchetto di Serviceguard è possibile applicare un criterio che utilizzi i compartimenti fss pset a solamente uno dei domini di risorse condivise in cui può eseguire il failover. In tutti gli altri domini di risorse condivise in cui il carico di lavoro può eseguire il failover, sarà necessario applicare un criterio ad un'istanza di sistema operativo contenitore (partizione virtuale o nPartition). È possibile utilizzare un criterio condizionale di gWLM per modificare l'assegnazione delle risorse secondo quali pacchetti sono presenti. Con una macchina virtuale è associata ad un pacchetto di Serviceguard, dato che in ciascun host la macchina virtuale è rappresentata da un carico di lavoro distinto, gestire semplicemente ciascun carico di lavoro nel dominio di risorse condivise in modo indipendente in ciascun host di macchine virtuali. L'uso di processori della cella locale in partizioni virtuali all'interno di una nPartition che utilizza Instant Capacity (iCAP) causa errori del comando icod_modify. Non assegnare CPU utilizzando la specificazione della cella. Prendere in considerazione l'assegnazione di CPU alle partizioni virtuali utilizzando un percorso hardware. In alternativa, per utilizzare processori locali della cella, aggiornare a vPars A.04.04 con HP-UX 11i v2 (B.11.23) oppure a vPars A.05.01 con HP-UX 11i v3 (B.11.31). Global Workload Manager consente a più domini di risorse condivise in un complesso di usare TiCAP; si dovrebbe però impedire che questa situazione si verifichi. Le modifiche alla configurazione di un dominio di risorse condivise di grande dimensione messo in attività potrebbero richiedere molto tempo (diversi minuti) per avere effetto. I prodotti HP System Fault Management (SFM) ed Event Monitoring Service – in particolare i monitor hardware EMS – generano degli eventi, o indicazioni, alla migrazione delle CPU. Secondo le caratteristiche del carico di lavoro, gWLM è in grado di migrare rapidamente le CPU. Nel corso del tempo, questa frequente migrazione può portare ad un numero di eventi sufficientemente elevato da influire negativamente sulle prestazioni del server di amministrazione centrale di HP SIM. Come soluzione, sono disponibili le seguenti possibilità:
Per maggiori informazioni su queste soluzioni, vedere la documentazione di HP SIM, disponibile all'indirizzo http://www.hp.com/go/hpsim. La risposta del server di amministrazione centrale è lenta. Cronometrare l'esecuzione del comando gwlm list nel server di amministrazione centrale. Se richiede più di 10 secondi, eseguire le operazioni seguenti:
È possibile installare una versione più recente dell'agente gWLM in un server di amministrazione centrale che usa una versione precedente di gWLM. Ad esempio, è possibile installare l'agente A.03.00.00 in un sistema con la versione A.02.00.00.x del server di amministrazione centrale. Questa configurazione non è valida e rende il sistema inutilizzabile. Aggiornare la versione del server di amministrazione centrale. L'aggiornamento installa anche l'agente corrispondente. Dato che gWLM che in tutti i nodi amministrati del dominio di risorse condivise la versione degli agenti sia la stessa, sarà necessario aggiornare gli agenti in tutti i nodi amministrati che possono trovarsi del dominio di risorse condivise che comprende il server di amministrazione centrale. Per ulteriori informazioni su come eseguire questo aggiornamento, consultare Guida di installazione ed aggiornamento del software di amministrazione VSE. Una volta emessa una richiesta d'eliminazione di un carico di lavoro, potrebbe essere necessario un tempo relativamente lungo (diversi minuti) per portare a termine la cancellazione. Rimuovere dal database di gWLM i vecchi dati cronologici di monitoraggio e configurazione, eseguendo il comando seguente:
Nel caso non si desideri limitare il database, è possibile eliminare più carichi di lavoro simultaneamente, con il comando gwlm delete. Per ulteriori informazioni, consultare gwlm(1M). Quando l’agente gWLM è installato in un sistema con installato VM Integrity VM, le operazioni di rilevamento segnalano solamente i compartimenti di Integrity VM, anche se sono presenti pset e gruppi fss. Con l'interfaccia a riga dei comandi di gWLM, non è possibile aggiungere un carico di lavoro al dominio di risorse condivise con una partizione annidata, a meno che un carico correlato non sia già amministrato nel dominio di risorse condivise.
Il problema non si verifica utilizzando l'interfaccia gWLM di HP SIM. Seguire semplicemente le istruzioni del Punto 1 della procedura guidata "Manage Systems and Workloads" – utilizzabile selezionando Create Nel tentativo di rimuovere da un dominio di risorse condivise con partizioni annidate l'ultimo gruppo FSS [predefinito], potrebbe essere visualizzato un messaggio che comprende il testo seguente: Unable to remove workload nome_carico_lavoro: Attempting to remove a compartment with an unachievably low Fixed policy size. Increase the Fixed policy resource amount and try again. Durante il monitoraggio di un dominio di risorse condivise con partizioni virtuali in una nPartition di un sistema HP-UX 11i v1, la dimensione monitorata della nPartition potrebbe non essere aggiornata. Se è stato installato gWLM A.03.00.00 in un sistema in cui è stato installato Integrity VM A.02.00, in syslog saranno presenti dei messaggi nella forma seguente: vm_fssagt[2461]: dangerous REALTIME job 2686 gwlmagent Al posto di gwlmagent potrebbe essere indicato parstatus, HPUXChildWrap o wbemexec. Potrebbe essere visualizzato un messaggio simile al seguente: Information Error during shutdown. The unbinding of objects in the registry may have failed, and the workload management lock has not been released. Associated Exception com.hp.gwlm.common.JniPlatformException: prm_ctrl_rel_cfg_lock failed because vm_fssagt:8343 is the lock owner Quando in un sistema sono utilizzati i pset, per i gruppi FSS gWLM usa il pset 0. gWLM è solamente in grado di amministrare solamente le CPU assegnate al pset 0. Non esiste una soluzione; questa è la modalità di implementazione dei gruppi FSS in un sistema che utilizza i pset. È possibile continuare a utilizzare i gruppi FSS nel pset 0, lasciando gli altri pset non amministrati, amministrare utilizzando invece i pset, ignorando i gruppi fss, oppure rimuovere tutti i pset, diversi quello 0, con il comando seguente:
Il rilevamento di Global Workload Manager non segnala sempre le informazioni aggiornate delle macchine virtuali arrestate. In particolare, quando una macchina virtuale è arrestata ed è stato modificato il numero di vCPU, il rilevamento fatto da gWLM non mostra il nuovo numero di vCPU. Segnala invece il numero di vCPU del più recente avvio della macchina virtuale. In quanto applicazione client/server, gWLM è maggiormente sensibile, rispetto ad altri tipi di applicazioni, alla configurazione di rete del proprio host. gWLM supporta l'amministrazione soltanto all'interno di un singolo dominio di rete. Se, ad esempio, il proprio host del server di amministrazione centrale ha più schede di rete connesse a più reti distinte tra loro, gWLM richiede che il nome host completamente qualificato sia convertito nell'indirizzo IP che sarà raggiungibile dagli agenti gWLM da amministrare. Questo problema è sovente fastidioso quando un host è connesso ad entrambi i soggetti seguenti:
Global Workload Manager tenta di rilevare e di segnalare i problemi di configurazione di rete che possono essere causa di funzionamenti indesiderati, ma, in alcuni casi, il rilevamento avviene in un contesto che può essere segnalato solamente in un file di log. gWLM non supporta gli alias dei nomi host. Sono supportati solamente i nomi host DNS canonici (nomi di dominio completamente qualificati). I nomi host non possono avere lunghezza superiore a 64 caratteri. Il seguente messaggio potrebbe essere visualizzato nell'interfaccia gWLM di HP SIM: Unable to build a single shared resource domain from the set of specified hosts: nome_host_A.nome_dominio.com nome_host_B.nome_dominio.com Questo messaggio indica che negli host specificati non sono disponibili meccanismi supportati di condivisione delle risorse. Il messaggio può essere visualizzato se:
Se è ricevuto questo messaggio:
Il seguente messaggio potrebbe essere visualizzato quando si usa la procedura guidata "Manage New Systems" o il comando gwlm discover: Error during discovery of compartments. Inoltre, il file /var/opt/gwlm/gwlmagent.log.0 conterrà il seguente messaggio: com.hp.gwlm.common.PlatformException: /usr/sbin/parstatus -w exited with a non-zero exit status. Captured stderr is: Error: Unable to get the local partition number. La causa più probabile è la presenza di una versione superata del software nPartition Provider. Per stabilire le capacità del sistema, Global Workload Manager utilizza un comando fornito dal nPartition Provider, che è generalmente disponibile in ogni versione di HP-UX. Per diagnosticare il problema, è inoltre possibile utilizzare il comando /opt/vse/bin/vseassist. Installare la versione più recente del software per le nPartition, anche se non le si utilizza. HP-UX 11i v1 richiede la versione B.11.11.01.03.01.01 o successiva. Con HP-UX 11i v2 nei server HP 9000, è necessario utilizzare la versione B.11.23.01.03.01.01 o successiva. Con HP-UX 11i v2 nei server HP Integrity, è necessario utilizzare la versione B.11.23.01.04 o successiva. È possibile trovare nPartition Provider nei luoghi seguenti:
Occasionalmente, un agente gWLM ed il server di amministrazione centrale gWLM possono non essere d’accordo se un dominio di risorse condivise è stato effettivamente messo in attività. Questo può verificarsi quando si utilizza Ctrl-C per interrompere il comando gwlm deploy o il comando undeploy. Può verificarsi anche in caso di errori durante il salvataggio di una configurazione di gWLM. La configurazione è messa in attività, quindi salvata nell'archivio delle configurazioni gWLM. Nel caso che avvenga la messa in attività, ma non il salvataggio, l'agente gWLM considererà il dominio di risorse condivise come in attività, mentre il server di amministrazione centrale lo considererà come non in attività. Utilizzare l'opzione --force con gwlm deploy oppure con gwlm undeploy per sincronizzare nuovamente l'agente ed il server di amministrazione centrale. Ad esempio, per forzare sia l'agente sia il server di amministrazione centrale a considerare il dominio di risorse condivise come in attività, eseguire il comando seguente, sostituendo a dominio_risorse_condivise il nome del proprio dominio:
Per maggiori informazioni sul comando gwlm, consultare gwlm(1M). È ripetutamente visualizzato un messaggio simile a uno dei seguenti:
Questa situazione è normale, tranne quando il medesimo blocco – utente ed orario – dura più di 10 minuti. In tal caso, è possibile rimuovere il blocco arrestando e riavviando gwlmcmsd, anche se sarà necessario attendere fino ad un minuto prima di poter utilizzare gWLM. Usare i comandi seguenti:
Potrebbero non essere disponibili dati cronologici per i grafici – anche si è sicuri che nel lasso di tempo in questione è stato messo in attività un dominio di risorse condivise. Un problema correlato si verifica quando si seleziona un periodo in cui ci si aspetta un'elevata attività del sistema, ma il grafico mostra un'attività limitata. Analogamente, ci si aspetta un'attività minima in un dato lasso di tempo, ma il grafico mostra un'attività elevata. Controllare che l'orologio di sistema del server di amministrazione centrale e quelli di tutti i domini di risorse condivise siano sincronizzati. Se gli orologi segnano orari decisamente diversi, gWLM potrebbe non essere in grado di far coincidere i dati dei nodi amministrati con il periodo di cui si desidera il grafico. Tentando di visualizzare dei rapporti in tempo reale, si riceve il messaggio seguente: Real-time data is currently loading, please wait... You might also verify that the remote node is running and SRDs have been deployed. Questa situazione è di norma solo temporanea. Se dovesse persistere, controllare che il daemon gwlmagent sia in esecuzione nei nodi remoti. Se è in esecuzione, fermarlo e riavviarlo. Nel caso che tale situazione persista, interrompere e ripetere la messa in attività del dominio di risorse condivise. Global Workload Manager potrebbe non aggiornare il monitoraggio di un dominio di risorse condivise – nella riga dei comandi oppure tramite l'interfaccia grafica in HP SIM. Questo può essere causato da un timeout durante i tentativi di riformare un dominio di risorse condivise, lasciandolo in uno stato in cui è necessario riavviare l'agente in ognuno dei suoi nodi amministrati. Una causa possibile può essere l'inattività di un nodo amministrato, la mancata esecuzione di gwlmagent nel nodo, oppure il blocco del nodo. Se il nodo amministrato è inattivo o gwlmagent non è in esecuzione, sarà visualizzato il seguente messaggio: The gWLM agent process on the host is not running -- start the agent and retry. Se il nodo amministrato è bloccato o il dominio di risorse condivise richiede il riavvio di tutti i suoi agenti, i sintomi possono comprendere:
Se un dominio di risorse condivise non offre monitoraggio in tempo reale per un periodo di tempo prolungato, riavviare l'agente gWLM in ogni nodo amministrato del dominio di risorse condivise. Nel caso di un blocco anomalo di un membro del dominio di risorse condivise, mentre il monitoraggio in tempo reale del dominio è bloccato, gli altri domini di risorse condivise continuano ad amministrare risorse. Tuttavia, il monitoraggio in tempo reale di altri domini di risorse condivise potrebbe essere bloccato a causa del blocco anomalo del membro del dominio di risorse condivise. Per ripristinare il monitoraggio degli altri domini di risorse condivise:
Il comando gwlm monitor non sembra funzionare correttamente. Un rapporto di gwlmreport è basato su un periodo che parte da mezzanotte di un dato giorno e termina la mezzanotte del giorno seguente. Qualsiasi campione che si sovrappone all’ora iniziale oppure a quella finale del periodo sarà escluso dal rapporto. Questo problema interessa solamente gli agenti gWLM A.02.00.00.x. I valori di weight per i criteri consentono a gWLM di stabilire l’assegnazione delle risorse in caso di loro eccesso. Impostando al medesimo valore tutti i criteri per weight utilizzati in un dominio di risorse condivise, le risorse dovrebbero essere assegnate ai carichi di lavoro associati un modo bilanciato. Tuttavia, in un dominio di risorse condivise, impostando a zero tutti i criteri farà sì che ad un singolo carico di lavoro siano assegnate tutte le risorse in eccesso. In un dominio di risorse condivise con partizioni annidate, assegnando criteri fissi in cui la somma dei valori fissi è inferiore al minimo del compartimento di livello superiore, può far sì che il carico di lavoro riceva più risorse di quelle specificate dai criteri fissi. Questo problema interessa sia gli agenti gWLM A.01.01.x sia quelli gWLM A.02.00.00.x. Il valore per il tasso di convergenza specificabile facoltativamente quando di definisce un criterio, attualmente ha effetto solo sui criteri personalizzati. I criteri per OwnBorrow e l’utilizzo non ne sono influenzati. I criteri personalizzati utilizzano dei valori metrici forniti tramite il comando gwlmsend. Ripetendo la messa in attività di un dominio di risorse condivise che abbia un criterio personalizzato, il valore più recente della metrica del criterio va perduto. In tale situazione, gWLM basa le sue assegnazioni sulla richiesta minima specificata nel criterio del carico di lavoro. Il carico di lavoro può ricevere le risorse di CPU rimanenti dopo che tutti i criteri sono stati soddisfatti. Il tentativo di utilizzare i comandi gwlm porta al dumping quando /var è piena. Una prima soluzione è di liberare dello spazio in /var. Una soluzione più valida è di aggiornare la versione di Java. Se è utilizzata una variante di Java 1.4.2, assicurarsi che sia almeno la versione 1.4.2.10. Se è utilizzata una variante di Java 1.5, non è al momento disponibile una correzione. Potrebbe essere visualizzato un messaggio contenente il testo seguente: ...unable to create new native thread Questo problema si verifica perché i seguenti parametri del kernel sono impostati con valori troppo bassi:
In genere, gWLM non consente, in una singola nPartition o in un singolo sistema, la creazione nello stesso momento di più domini di risorse condivise basati su partizioni virtuali. Tuttavia, quando più utenti gWLM mettono in attività quasi nello stesso momento più domini di risorse condivise, gWLM potrebbe inavvertitamente consentire questi domini multipli. Potrebbe essere visualizzato un messaggio simile al seguente: Error trying to deploy SRD, nome_sistema.vpar.000 to nome_sistema_2.nome_dominio.com. SRD, nome_sistema_2.fss.000 is already deployed. Only one SRD is allowed to be deployed. Con HP-UX 11i v2 (B.11.23), un'applicazione all'interno di un gruppo FSS potrebbe bloccarsi quando è eseguita in una partizione virtuale, nPartition, o sistema a singolo processore. Quando è definito un criterio condizionale in un file di configurazione XML con l'elemento compositePolicyDefinition, la condizione è specificata gli elementi conditionItem. Per ciascun elemento conditionItem, è specificato un valore di ordine che gWLM utilizza per determinare l'ordine di valutazione. gWLM al momento accetta il medesimo valore di ordine per elementi conditionItem differenti nello stesso elemento compositePolicyDefinition, ma non riesce a valutarli, senza segnalarlo. In questo caso, gWLM dovrebbe segnalare un errore. Con i compartimenti basati su pset o gruppi fss, gWLM consente di collocare gli script in questi compartimenti, utilizzando dei record di applicazioni con nomi alternativi. Questo funziona solamente se la shell – o interprete – utilizzata è elencata nel file /etc/shells. In genere, perl non è contenuto in questo file. Gli script perl – ed altri script basati su shell o interpreti non elencati in in /etc/shells – non sono perciò collocati correttamente. Questo problema non riguarda gli eseguibili. Aggiungere /opt/perl/bin/perl e qualsiasi altra shell o interprete, al file /etc/shells. Global Workload Manager riconoscerà le shell e gli interpreti aggiunti entro 30 secondi.
Tutte le assegnazioni dei processi eseguite con il comando gwlmplace in un nodo amministrato andranno perse se:
In questi casi, i processi saranno collocati secondo i record delle applicazioni, oppure secondo i record utente validi. Se non esistono record, i processi non di root sono collocati nei pset o nei gruppi FSS predefiniti; i processi di root sono lasciati dove si trovano. Quando gWLM gestisce i pset in un sistema, ogni processo del sistema deve andare ad un carico di lavoro. gWLM colloca i processi secondo i record delle applicazioni o degli utenti, specificati al momento delle creazione o della modifica della definizione del carico di lavoro. Nel caso non esistano record, i processi sono soggetti alle regole di collocazione, descritte nella guida in linea, in "pset / fss group tips", nella sezione "Precedence of placement techniques". Utilizzando il comando psrset per la collocazione dei processi nei pset, gWLM molto probabilmente sposterà i processi nel pset predefinito. Per conservare la collocazione di un processo, in gWLM, durante la creazione o la modifica delle definizioni dei carichi di lavoro utilizzare i record delle applicazioni o quelli degli utenti di gWLM. Se l'utilizzo dei record non è pratico, utilizzare il comando gwlmplace. Tuttavia, sarà necessario utilizzare gwlmplace ogni volta che sarà ripetuta la messa in attività di un dominio di risorse condivise, per riportare il processo nel carico di lavoro desiderato. I gruppi FSS creati da gWLM possono diventare abbandonati e non è possibile rimuoverli facilmente. Questa situazione si verifica per diverse ragioni. Un caso è quando gestendo un dominio di risorse condivise basato sui gruppi FSS, è utilizzato un secondo server di amministrazione centrale, per esempio a causa dell'inattività del primo. Ciò può lasciare il dominio di risorse condivise con dei gruppi FSS che non è possibile rimuovere. Utilizzando l'interfaccia di HP SIM, è possibile creare un nuovo dominio di risorse condivise che integri automaticamente i gruppi FSS esistenti. In alternativa, è possibile rimuovere i gruppi FSS, nel qual caso esistono più opzioni. Se è installato PRM, eseguire il comando seguente:
Se non è installato PRM, eseguire la seguente procedura:
I gruppi fss ora dovrebbero essere stati eliminati dal sistema. Tuttavia, le loro definizioni dei carichi di lavoro si troveranno ancora nell'archivio delle configurazioni di gWLM. È possibile rimuovere queste definizioni e le definizioni dei domini di risorse condivise, utilizzando l'interfaccia gWLM di HP SIM. Scegliere Tools Le dimensioni o le assegnazioni per le macchine virtuali in un dominio di risorse condivise in attività potrebbero sembrare inferiori ai valori minimi dei loro criteri. Se le CPU in un host di macchine virtuali sono assegnate in numero eccessivo quando si mette in attività un dominio di risorse condivise in quell'host, gWLM presenta la dimensione corrente di NONVM come valore negativo. Quando si tenta di interrompere l'amministrazione di una macchina virtuale già avviata, l'attività del dominio di risorse condivise potrebbe essere arrestata, anche se è visualizzato il seguente messaggio: The virtual machine nome_macchina_virtuale on host nome_host is on but does not have an associated gWLM policy. Please turn the virtual machine off, or apply a gWLM policy to provide the necessary resources. Global Workload Manager è ideato per utilizzare le estensioni .log.0, .log.1 e .log.2 per i suoi file di log. Un blocco Java dei file garantisce che solamente un unico processo gWLM sia in grado di aggiornare un file di log in qualsiasi momento. A partire da Java 1.4.2.06, il blocco dei file consente la creazione di file con estensione nella forma .log.0.n, dove n è un numero intero. Se si utilizza Java versione 1.4.2.06 o successiva e si desidera controllare nei file di log la presenza di errori, per cercare quali file contengono messaggi di errore recenti, utilizzare il seguente comando:
Quindi, sarà possibile utilizzare /usr/bin/tail per visualizzare i messaggi nei file di log aggiornati di recente. Se i file di log devono essere inviati all’assistenza HP, creare un file tar usando i comandi seguenti:
Inviare quindi all'assistenza HP il file /tmp/gwlmlogs4support.tar. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 Versione stampabile |
|
|
|
|
|
|||||||||||||||
|
|||||||||||||||
Remove Associated gWLM Policy.
