Considerazioni sulla progettazione di pool di risorse

Importante

Questa versione di Operations Manager ha raggiunto la fine del supporto. È consigliabile eseguire l'aggiornamento a Operations Manager 2022.

Un pool di risorse è un raggruppamento logico di server di gestione e/o server gateway usati per distribuire il lavoro tra tali server e rilevare il carico di lavoro di un membro con errori. In altri termini, assicurano disponibilità elevata e scalabilità per i flussi di lavoro. Quando si progetta un gruppo di gestione, è necessario prendere in considerazione alcuni fattori riguardo al monitoraggio di dispositivi di rete, sistemi Linux/UNIX e altri carichi di lavoro progettati per sfruttare i vantaggi di un pool di risorse.

Panoramica

I pool di risorse garantiscono la continuità del monitoraggio fornendo più membri, che sono server di gestione e/o server gateway in grado di assumere il monitoraggio dei flussi di lavoro se uno dei membri del pool non è più disponibile. È possibile creare pool di risorse per scopi specifici. Si potrebbe ad esempio creare un pool di risorse di server di gestione nel data center primario per monitorare i dispositivi di rete.

I pool di risorse applicano una logica simile al clustering "set di nodi di maggioranza", dove (< numero di nodi come membri del pool > /2) + 1. Per mantenere il quorum, devono essere presenti almeno tre membri del pool, che devono essere più del 50% dei membri di voto del quorum in un pool per mantenere la disponibilità del pool. Se sono presenti solo due membri del pool e uno non è disponibile, si è perso il quorum.

Per ogni pool di risorse creato nella Console operatore, il database di Operations Manager, denominato osservatore predefinito, riceve sempre un voto, anche se si ha un numero pari di membri nel pool per consentire il raggiungimento del quorum. Questo vale anche per i tre pool di risorse creati per impostazione predefinita quando si crea per la prima volta il gruppo di gestione, descritto più avanti in questo articolo. Per tutti i pool di risorse creati usando il cmdlet di PowerShell NewSCOM ResourcePool, è impostato su disabilitato per impostazione predefinita. L'inclusione del database di Operations Manager come osservatore predefinito riduce la complessità del gruppo di gestione poiché richiede soltanto la distribuzione di un minimo di due server di gestione per mantenere un'elevata disponibilità del pool di risorse.

Un altro ruolo a supporto dei pool di risorse è quello degli osservatori. Si tratta di un server di gestione o di un server gateway che non partecipa al caricamento dei flussi di lavoro per il pool; tuttavia, partecipano alle decisioni relative al quorum. Non viene mai usato in circostanze normali e pertanto non deve essere considerato.

Esistono due tipi di appartenenza:

• Automatico
• Manuale

Quando si crea un pool di risorse, la relativa appartenenza viene impostata come manuale e non può essere riconfigurata come automatica. Quando si crea un gruppo di gestione di System Center - Operations Manager, per impostazione predefinita vengono creati tre pool di risorse con appartenenza automatica. La tabella seguente descrive questi tre pool di risorse.

Nome del pool di risorse	Descrizione
Pool di risorse per tutti i server di gestione	Esegue flussi di lavoro per il calcolo dei gruppi, la disponibilità, il rollup dell'integrità dei monitoraggi distribuiti e la pulitura dei database.
Pool di risorse per le notifiche	I flussi di lavoro del servizio di sottoscrizione avvisi hanno come destinazione questo pool di risorse per supportare le notifiche di avviso.
Pool di risorse per l'assegnazione di Active Directory	I flussi di lavoro di integrazione di Active Directory hanno come destinazione questo pool di risorse per supportare l'assegnazione automatica di agenti ai server di gestione.

Poiché l'appartenenza al pool di risorse per tutti i server di gestione è automatica, qualsiasi server di gestione autorizzato viene automaticamente reso membro del pool di risorse. In alcune architetture e in particolari considerazioni sulla progettazione, ad esempio quelle riguardanti operazioni di emergenza in più aree geografiche, l'assegnazione automatica al pool di risorse per tutti i server di gestione può non essere un'opzione desiderata. In queste situazioni, è possibile modificare l'assegnazione dell'appartenenza da automatica a manuale. Di conseguenza, i server di gestione devono essere aggiunti al pool di risorse per tutti i server di gestione mediante un'assegnazione manuale.

Nota

L'appartenenza del pool di risorse di tutti i server di gestione è di sola lettura. Per modificare l'appartenenza da automatica a manuale, vedere Modifica dell'appartenenza al pool.

Con l'introduzione dei pool di risorse, è consigliabile che tutti i membri siano connessi da una rete a bassa latenza (minore di 10 ms). I pool di risorse non devono essere distribuiti in più data center o in un ambiente cloud ibrido come Microsoft Azure.

Esempi di disponibilità dei pool di risorse

Negli esempi seguenti viene illustrato il concetto di disponibilità dei pool di risorse sulla base delle configurazioni seguenti, solo con i server di gestione o solo con i server gateway.

Server di gestione unico

• L'osservatore predefinito è abilitato per impostazione predefinita e non offre vantaggi perché sono presenti solo due membri e non viene raggiunto il quorum.
• Non esiste una disponibilità elevata perché il server di gestione è un singolo punto di errore.

Due server di gestione

• L'osservatore predefinito è abilitato per impostazione predefinita.
• La disponibilità elevata per il pool è elevata perché sono presenti tre membri di voto, due server di gestione e l'osservatore predefinito.
• Se si disabilita l'osservatore predefinito, si perderà la disponibilità elevata per il pool.

Tre server di gestione

• L'osservatore predefinito è abilitato per impostazione predefinita.
• La disponibilità elevata per il pool è elevata, perché sono presenti quattro membri di voto, tre server di gestione e l'osservatore predefinito.
• Per impostazione predefinita è possibile avere un solo server di gestione non disponibile per mantenere il quorum. Se due server di gestione non sono disponibili, sono presenti esattamente il 50% dei membri di voto e il pool di risorse non funziona più per gestire i carichi di lavoro di monitoraggio.
• L'osservatore predefinito non aumenta il numero di server di gestione che possono essere inattivi, pertanto non aumenta la disponibilità del pool.
• In questo scenario, è possibile valutare di rimuovere l'osservatore predefinito.

Quattro server di gestione

• L'osservatore predefinito è abilitato per impostazione predefinita.
• È disponibile una disponibilità elevata per il pool, perché sono presenti cinque membri di voto, quattro server di gestione e l'osservatore predefinito.
• Per impostazione predefinita, è possibile avere solo due server di gestione non disponibili per mantenere il quorum. Se tre server di gestione sono inattivi, sono presenti meno del 50% dei membri di voto e il pool di risorse non funziona più per gestire i carichi di lavoro di monitoraggio.
• In questo scenario, l'osservatore predefinito assume un valore significativo, poiché aumenta il numero di server di gestione che possono essere inattivi. Senza l'osservatore predefinito, si hanno solo quattro membri del quorum, il che consente di avere un solo membro non disponibile.

Cinque server di gestione

• L'osservatore predefinito è abilitato per impostazione predefinita.
• È disponibile una disponibilità elevata per il pool, perché sono presenti sei membri di voto, cinque server di gestione e l'osservatore predefinito.
• Per impostazione predefinita è possibile avere solo due server di gestione non disponibili per mantenere il quorum. Se non sono disponibili tre server di gestione, ciò corrisponde esattamente al 50% dei membri votanti e il pool di risorse non funzionerà più per gestire i carichi di lavoro di monitoraggio.
• L'osservatore predefinito non aumenta il numero di server di gestione che possono essere inattivi, pertanto non aumenta la disponibilità del pool.
• In questo scenario, è possibile valutare di rimuovere l'osservatore predefinito.

Dopo aver raggiunto tre o più server di gestione in un pool di risorse, in cui è presente un numero dispari di membri nel pool, è possibile rimuovere l'osservatore predefinito come membro. Se si raggiungono cinque server di gestione, è possibile che il database operativo abbia un carico significativo, che potrebbe generare una latenza sufficiente per influire sui calcoli del pool di risorse.

Con il ruolo svolto dall'osservatore predefinito, ogni server di gestione nel pool esegue una query nel proprio servizio SDK locale, consentendo di eseguire query in una tabella nel database operativo per l'osservatore predefinito. Se il servizio SDK o il database è in fase di caricamento, si verifica una latenza che altrimenti non esiste.

Server gateway unico

• L'osservatore predefinito è abilitato per impostazione predefinita.
• Non esiste una disponibilità elevata perché il server gateway è un singolo punto di errore.
• L'osservatore predefinito non deve essere usato qui perché i server gateway non dispongono di un servizio SDK locale e pertanto non possono eseguire query sul database operativo.

Due server gateway

• L'osservatore predefinito è abilitato per impostazione predefinita.
• Non esiste una disponibilità elevata perché sono presenti solo due membri del pool e l'osservatore predefinito non è un partecipante perché i server gateway non comunicano direttamente con il database operativo. Per mantenere il quorum del pool sono necessari tre server gateway.

Tre server gateway

• L'osservatore predefinito è abilitato per impostazione predefinita.
• La disponibilità elevata per il pool è elevata perché sono presenti tre membri di voto, tre server gateway.
• Per impostazione predefinita, è possibile avere un solo server gateway non disponibile per mantenere il quorum. Se sono inattivi tre server gateway, è disponibile meno del 50% dei membri votanti e il pool di risorse non funzionerà più per gestire i carichi di lavoro di monitoraggio.
• L'osservatore predefinito non deve essere usato qui perché i server gateway non dispongono di un servizio SDK locale e pertanto non possono eseguire query sul database operativo.

Scenari di monitoraggio che supportano pool di risorse

I flussi di lavoro seguenti sono ospitati da pool di risorse in Operations Manager:

• Gestione dei dispositivi di rete
• Gestione degli agenti UNIX/Linux
• Monitoraggio degli URL di applicazioni Web

Nota

Gli agenti Windows non fanno riferimento a pool di risorse.

Il monitoraggio di rete in Operations Manager richiede un proprio pool di risorse separato e dedicato. Il motivo è che i flussi di lavoro del monitoraggio della rete vengono eseguiti sui server di gestione (sul modulo SNMP) e non sugli agenti. Se si include il monitoraggio delle porte di rete, in particolare se si seleziona la maggior parte delle porte attive disponibili nel dispositivo, questa condizione determina un carico di lavoro non indifferente sui server di gestione. Di conseguenza, per migliorare le prestazioni si consiglia di usare server di gestione dedicati in pool di risorse destinate al monitoraggio della rete. Inoltre, i server di gestione membri di questo pool devono essere rimossi dal pool di risorse per tutti i server di gestione, dal pool di risorse per le notifiche e dal pool di risorse per l'assegnazione di Active Directory.

In Operations Manager il monitoraggio dei sistemi Linux/UNIX può essere assegnato a un pool di risorse dedicato, se questo è necessario per abilitare il monitoraggio della disponibilità elevata e la gestione degli agenti. Tale assegnazione, tuttavia, non è obbligatoria. Operations Manager usa i certificati per autenticare l'accesso ai computer gestiti. Quando si utilizza Individuazione guidata per distribuire un agente, la procedura consente di recuperare il certificato dall'agente, firmarlo, ridistribuirlo all'agente e poi riavviare l'agente. Per supportare la disponibilità elevata, ciascun server di gestione del pool di risorse deve essere dotato di tutti i certificati radice usati per firmare i certificati distribuiti agli agenti nei computer UNIX e Linux. In caso contrario, se un server di gestione non è disponibile, gli altri server di gestione non sarebbero in grado di considerare attendibili i certificati firmati dal server non riuscito.

Passaggi successivi

Per informazioni su come creare e gestire pool di risorse, vedere Come gestire i pool di risorse.