| Italia - Italiano |
|
|
|
![]() |
HP Integrity Essentials Capacity Advisor: Manuale per l'utente > Capitolo 6 Capacity Advisor e ServiceguardUso di Capacity Advisor assieme a Serviceguard |
|
In un centro dati, è probabile l'uso contemporaneo di Capacity Advisor e di Serviceguard. Serviceguard organizza i sistemi o nodi in cluster. Un un ambiente Serviceguard, applicazioni, servizi ed altre entità sono organizzate come pacchetti e possono essere spostati da un nodo del cluster ad un altro. Il software di amministrazione VSE organizza le applicazioni in carichi di lavoro. Capacity Advisor raccoglie i dati di utilizzo di sistemi e carichi di lavoro. Quando un pacchetto esegue il failover da un sistema ad un altro, può spostarsi anche un carico di lavoro che Capacity Advisor sta controllando. Capacity Advisor continuerà a controllare il carico di lavoro nel vecchio sistema finchè esso non sarà modificato o aggiornato con il nome host del nuovo sistema. I pacchetti di Serviceguard ed i carichi di lavoro di Capacity Advisor sono definiti indipendentemente, ma possono sovrapporsi. Configurando Capacity Advisor per controllare carichi di lavoro eseguiti in un cluster Serviceguard, vi sono varie possibilità:
Questo è il modo più semplice per configurare Capacity Advisor. È facile da mettere in pratica ed è la prassi da seguire se Serviceguard non è presente. Lo svantaggio è che quando in Serviceguard si verifica un failover, i dati di utilizzo registrati da Capacity Advisor scendono tutti a zero; non sono presenti valori di utilizzo quando il carico di lavoro è in esecuzione in un altro sistema. Dopo che il pacchetto sarà tornato al sistema abituale, sarà necessario utilizzare Profile Editor di Capacity Advisor per contrassegnare le voci di utilizzo zero come dati non validi. Questo garantirà che i valori a zero non saranno usati per l'elaborazione delle medie ed altre metriche di utilizzo. Scegliere questa soluzione per minimizzare il tempo in cui un pacchetto è eseguito in sistemi diversi da quello abituale. Se il pacchetto è configurato con il criterio di failover MIN_PACKAGE_NODE, potrebbe non essere ovvio stabilire qual'è il “sistema abituale”, perché il pacchetto è avviato dove c'è il minor numero di pacchetti. Se gli altri pacchetti sono configurati con il criterio CONFIGURED_NODE, l'amministratore può essere in grado di capire qual'è il sistema abituale. Per i pacchetti con il criterio CONFIGURED_NODE, il “sistema abituale” è il primo dell'elenco dei nodi. La relazione tra carichi di lavoro e pacchetti non è 1:1, ma piuttosto n:1. Quando si configura il software di amministrazione VSE, è possibile definire un carico di lavoro per ogni pacchetto di Serviceguard in ciascun nodo del cluster in cui può essere eseguito tale pacchetto. (Questo vale solo per i pacchetti costituiti da uno o più processi.) I pacchetti che corrispondono a parte di un processo, un file oppure ad un indirizzo IP non possono corrispondere ad un carico di lavoro VSE, perchè esso è una raccolta di processi. Definendo un carico di lavoro VSE per ciascun nodo del cluster, Capacity Advisor potrà raccogliere i dati di utilizzo indipendentemente da dove il carico di lavoro è in esecuzione. Capacity Advisor registrerà dei valori diversi da zero delle letture nel sistema in cui il carico di lavoro è effettivamente in esecuzione e dei valori pari a zero per i carichi di lavoro definiti nei sistemi in cui il pacchetto non è in esecuzione. Quando si usa Capacity Advisor per simulare lo spostamento di un carico di lavoro in un altro sistema, spostare tutti i carichi di lavoro che rappresentano il medesimo pacchetto. Le voci a zero saranno sommate a quelle diverse da zero, per rappresentare il carico di lavoro in una traccia ininterrotta. Questa è una soluzione più completa rispetto a definire il carico di lavoro per dove è eseguito abitualmente il pacchetto, se quest'ultimo non ha un nodo del cluster in cui è eseguito abitualmente. È anche una soluzione più completa perchè si continuerà a raccogliere i dati quando il carico di lavoro è spostato a causa del failover di un pacchetto. Si dovrebbe usare Profile Editor di Capacity Advisor per contrassegnare come non valide le letture in prossimità del momento in cui il carico di lavoro era in transizione da un sistema all'altro. Durante questo periodo molti fattori influenzano le letture di utilizzo, come l'entrata in condizione di errore del sistema, il carico aggiuntivo dovuto al riavvio dell'applicazione e la domanda aggiuntiva dovuta alla rimozione delle richieste in arretrato, arrivate durate il rilevamento del malfunzionamento ed il riavvio del pacchetto. Questo picchi di utilizzo sono imprevedibili e non sono generalmente presi in considerazione durante la pianificazione della capacità. Dato che molti cluster di Serviceguard hanno solamente due nodi, questo può raddoppiare il numero di carichi di lavoro definiti, e definire i carichi di lavoro per ogni coppia di pacchetto/nodo potrebbe non essere una soluzione praticabile in cluster con molti nodi. Questa possibilità è impostata nello stesso modo della prima, definendo un carico di lavoro per dove è abitualmente eseguito il pacchetto. In questo modo, è definito un singolo carico di lavoro VSE per ogni applicazione in esecuzione nel cluster Serviceguard. Ogni carico di lavoro è definito per l'host in cui l'applicazione è inizialmente in esecuzione, il suo nodo primario. La differenza è che quando un pacchetto esegue il failover, qualcuno esegue manualmente VSE Manager e modifica il carico di lavoro per indicare che ora è in esecuzione in un altro sistema. Questo comporta l'esecuzione di cmviewcl, per scoprire dove è al momento in esecuzione il pacchetto che corrisponde al carico di lavoro. Questa informazione sarà quindi immessa nella pagina di Virtualization Manager per la modifica dei carichi di lavoro. Capacity Advisor raccoglierà in seguiti i dati, rileverà i dati del carico di lavoro in più di un sistema e li unirà in una singola traccia. Come per la seconda possibilità, definire un carico di lavoro per ciascuna coppia di pacchetto/nodo, i dati di utilizzo raccolti in prossimità del momento del failover devono essere contrassegnati come non validi. Questo periodo va dal momento subito prima del failover fino a quello della modifica del carico di lavoro per riflettere il suo spostamento in un altro sistema. Questa possibilità può essere la migliore nelle installazioni in cui il cluster ha vari nodi, oppure dove i pacchetti non tornano al nodo di origine del cluster appena possibile. In ogni caso, qualcuno dovrà controllare gli eventi di failover di Serviceguard ed aggiornare la definizione del carico di lavoro per riflettere il nuovo host. |
||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||