WebSphere Extended Deployment, Version 6.0.x     Sistemi operativi: AIX, HP-UX, Linux, Solaris, Windows, z/OS

Panoramica sugli esempi di gestione delle politiche

Se il cluster è in esecuzione, arrestarlo. Verificare inoltre che il gestore distribuzione e l'agente del nodo NodeA siano in esecuzione. Aprire una shell dei comandi e passare alla directory del gestore distribuzione \bin. Verificare che il filepolicyPK1_startup.properties creato precedentemente si trovi anche nella directory \bin del gestore distribuzione.

Emettere il seguente comando per caricare la politica appena creata:

wpfadmin createpolicy policyPK1_startup.properties

L'output generato dovrebbe avere il seguente aspetto. In caso contrario, verificare il file delle proprietà:
wsadmin -lang jython -f wpfadmin.pty createPolicy policyPK1_startup.properties
WASX7209I: Collegato al processo "Deployment Manager" sul nodo CellManager 
utilizzando il connettore SOAP; il tipo di processo è: DeploymentManager
La politica PK1StartupPolicy è stata creata
Il file coregroup.xml per il gestore distribuzione ha quindi la seguente politica:
<policies xmi:type="coregroup:OneOfNPolicy" xmi:id="OneOfNPolicy_1097944892103" 
name="PK1StartupPolicy" description="WPF Cluster Scoped Partition Policy 
Extended PK000001 Start" policyFactory="com.ibm.ws.hamanager.coordinator.policy.
impl.OneOfNPolicyFactory" isAlivePeriodSec="-1" quorumEnabled="true" 
failback="true" preferredOnly="true" preferredServers="CoreGroupServer_1097678779756
CoreGroupServer_1097678774418">
<MatchCriteria xmi:id="MatchCriteria_1097944898452" name="-gt" value="-p" 
description=",None"/>
<MatchCriteria xmi:id="MatchCriteria_1097944898532" name="-ps" value="-c" 
description=",None"/>
<MatchCriteria xmi:id="MatchCriteria_1097944898582" name="-pn" value="PK000001" 
description=",None"/>
</policies>
Se l'agente del nodo è in esecuzione, il file coregroup viene propagato. È possibile verificare la presenza del file ricercando la voce precedente nel file coregroup.xml. In caso contrario, il nodo viene sincronizzato in modo che l'aggiornamento della politica nel file coregroup possa essere propagato ai nodi del cluster. Per far ciò, con l'agente del nodo disabilitato, utilizzare il comando syncNode.

Dalla console di gestione, avviare il cluster.

Le partizioni vengono di solito avviate su cluster_member_2, quindi PK000001 deve essere l'unica partizione su cluster_member_1. Naturalmente la configurazione può essere differente. Per verificare in seguito all'avvio del cluster:

wpfadmin listActive

wsadmin -lang jython -f wpfadmin.pty listActive
WASX7209I: Collegato al processo "Deployment Manager" sul nodo CellManager 
utilizzando il connettore SOAP; il tipo di processo è: DeploymentMana
ger
WPFC0050I: Applicazione WPFKeyBasedPartitionSample, Partizione PK000010: 
Server Cell\NodeA\cluster_member_2
WPFC0050I: Applicazione WPFKeyBasedPartitionSample, Partizione PK000009: 
Server Cell\NodeA\cluster_member_2
WPFC0050I: Applicazione WPFKeyBasedPartitionSample, Partizione PK000008: 
Server Cell\NodeA\cluster_member_2
WPFC0050I: Applicazione WPFKeyBasedPartitionSample, Partizione PK000007: 
Server Cell\NodeA\cluster_member_2
WPFC0050I: Applicazione WPFKeyBasedPartitionSample, Partizione PK000006: 
Server Cell\NodeA\cluster_member_2
WPFC0050I: Applicazione WPFKeyBasedPartitionSample, Partizione PK000005: 
Server Cell\NodeA\cluster_member_2
WPFC0050I: Applicazione WPFKeyBasedPartitionSample, Partizione PK000004: 
Server Cell\NodeA\cluster_member_2
WPFC0050I: Applicazione WPFKeyBasedPartitionSample, Partizione PK000003: 
Server Cell\NodeA\cluster_member_2
WPFC0050I: Application WPFKeyBasedPartitionSample, Partition PK000002: 
Server Cell\NodeA\cluster_member_2
WPFC0050I: Applicazione WPFKeyBasedPartitionSample, Partizione PK000001: 
Server Cell\NodeA\cluster_member_1
Tutte le partizioni vengono avviate su cluster_member_2 invece che su cluster_member_1.

Per aggiornare la politica, è possibile aggiornare l'opzione –pn e regolarla in modo che venga applicata a PK000002. In alternativa, è possibile creare una seconda politica. Infine, è possibile anche arrestare semplicemente il membro del cluster 1, ad esempio stopserver cluster_member_1. In questo caso, poiché è impostata l'opzione Failback, il gestore HA prova a eseguire l'attivazione su cluster_member_2.

La politica può essere aggiornata mediante il seguente comando:

wpfadmin updatePolicy "PK1StartupPolicy" -failback true -preferredOnly
false -preferredServers NodeA/cluster_member_2,NodeA/cluster_member_1

Il comando restituisce il seguente output.
wsadmin -lang jython -f wpfadmin.pty updatePolicy PK1StartupPolicy 
-failback true -preferredOnly false -preferredServers NodeA/cluster_member_2,
NodeA/cluster_member_1
WASX7209I: Collegato al processo "Deployment Manager" sul nodo CellManager 
utilizzando il connettore SOAP; il tipo di processo è: DeploymentManager
La politica PK1StartupPolicy è stata aggiornata
Per eliminare la politica:

wpfadmin deletePolicy PK1StartupPolicy

wsadmin -lang jython -f wpfadmin.pty deletePolicy PK1StartupPolicy
WASX7209I: Collegato al processo "Deployment Manager" sul nodo CellManager 
utilizzando il connettore SOAP; il tipo di processo è: DeploymentMana
ger
La politica PK1StartupPolicy è stata eliminata
Se il cluster viene riavviato, è allora si è tornati agli algoritmi di gestione delle partizioni di avvio. Questo non è proprio il modo ottimale per modificare i server di avvio selezionati. Fare riferimento alla sezione relativa alle politiche del gestore HA per ulteriori informazioni.



Related tasks
Controllo delle statistiche delle prestazioni delle transazioni

Argomento Riferimenti    

Termini di utilizzo | Commenti Ultimo aggiornamento: Mar 20, 2006 1:10:47 PM EST
http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r0/index.jsp?topic=?topic=/com.ibm.websphere.xd.doc/info/WPF51/rwpfmanagepolicy.html

© Copyright IBM 2005, 2006. Tutti i diritti riservati.
Questo centro informazioni utilizza la tecnologia Eclipse. (http://www.eclipse.org)