Considerazioni sulla progettazione del pool di risorse

Un pool di risorse è un raggruppamento logico di server di gestione e/o server gateway usati per distribuire il lavoro tra loro e assumere il controllo del lavoro da un membro non riuscito. In altre parole, forniscono disponibilità elevata e scalabilità per i flussi di lavoro. Quando si progetta un gruppo di gestione, è necessario tenere conto del monitoraggio dei dispositivi di rete, dei sistemi Linux/UNIX e di altri carichi di lavoro progettati per sfruttare un pool di risorse.

Panoramica

I pool di risorse garantiscono la continuità del monitoraggio fornendo più membri, ovvero server di gestione e/o server gateway che possono assumere il controllo dei flussi di lavoro se uno dei membri del pool non è più disponibile. È possibile creare pool di risorse per scopi specifici. Ad esempio, è possibile 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 di "set di nodi di maggioranza", dove (< numero di nodi come membri del pool > /2) + 1. Per mantenere la disponibilità del pool, devono essere presenti almeno tre membri del pool, che devono essere più del 50% dei membri di voto quorum in un pool. Se si hanno 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, detto 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 il gruppo di gestione, illustrato 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 richiedendo solo di distribuire due server di gestione almeno per mantenere la disponibilità elevata dei pool di risorse.

Un altro ruolo che supporta un pool di risorse è Observer. 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. Questa operazione non viene mai usata in circostanze normali e pertanto non deve essere considerata.

Esistono due tipi di appartenenza:

• Automatico
• Manuale

Quando si crea un pool di risorse, l'appartenenza è impostata su manuale e non può essere riconfigurata in automatico. Quando viene creato un gruppo di gestione di System Center Operations Manager, vengono creati tre pool di risorse per impostazione predefinita con l'appartenenza automatica. Nella tabella seguente vengono descritti questi tre pool di risorse.

Nome pool di risorse	Descrizione
Pool di risorse tutti i server di gestione	Esegue flussi di lavoro per il calcolo del gruppo, la disponibilità, il rollup dell'integrità del monitoraggio distribuito e la pulitura del database.
Pool di risorse notifiche	I flussi di lavoro del servizio di sottoscrizione degli avvisi sono destinati a questo pool di risorse per supportare le notifiche di avviso.
Pool di risorse di assegnazione di Active Directory	I flussi di lavoro di integrazione di Active Directory sono destinati a questo pool di risorse per supportare l'assegnazione automatica degli agenti ai server di gestione.

Poiché l'appartenenza al pool di risorse Tutti i server di gestione è automatica, qualsiasi server di gestione commissionato viene automaticamente creato come membro di questo pool di risorse. In alcune architetture e considerazioni di progettazione, ad esempio quelle che incorporano operazioni di emergenza distribuite geograficamente, l'assegnazione automatica al pool di risorse Tutti i server di gestione potrebbe non essere desiderata. In queste situazioni, è possibile modificare l'assegnazione di appartenenza da automatica a manuale. Di conseguenza, i server di gestione devono essere aggiunti al pool di risorse Tutti i server di gestione tramite l'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 (inferiore a 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à del pool di risorse

Gli esempi seguenti illustrano il concetto di disponibilità del pool di risorse in base alle configurazioni seguenti, solo con server di gestione o solo con server gateway.

Server di gestione singolo

• L'osservatore predefinito è abilitato per impostazione predefinita e non offre alcun vantaggio perché non vengono raggiunti solo due membri e 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.
• È disponibile una disponibilità elevata per il pool 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.
• È disponibile una disponibilità elevata per il pool, 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, si dispone esattamente del 50% dei membri di voto e del 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 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.
• L'osservatore predefinito in questo scenario offre un valore significativo, perché aumenta il numero di server di gestione che possono essere inattivi. Senza l'osservatore predefinito, si dispone di solo quattro membri quorum, che consente solo a un membro di non essere 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 tre server di gestione non sono disponibili, questo è 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 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 subisca un carico significativo, che potrebbe generare una latenza sufficiente per influire sui calcoli del pool di risorse.

Con il modo in cui l'osservatore predefinito svolge un ruolo, ogni server di gestione nel pool esegue una query sul proprio servizio SDK locale, che consente di eseguire query su una tabella nel database operativo per l'osservatore predefinito. Se il servizio SDK o il database è sottoposto a un carico, si verifica una latenza che altrimenti non esiste.

Server gateway singolo

• 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 due server gateway sono inattivi, questo è inferiore al 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 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 i pool di risorse

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

• Gestione dei dispositivi di rete
• Gestione degli agenti UNIX/Linux
• Monitoraggio degli URL dell'applicazione Web

Nota

Gli agenti Windows non segnalano i pool di risorse.

Il monitoraggio di rete in Operations Manager richiede un pool di risorse separato e dedicato. Ciò è dovuto al fatto che i flussi di lavoro di monitoraggio della rete vengono eseguiti nei server di gestione (nel modulo SNMP) e non negli agenti. Questo comporta un carico elevato sui server di gestione dopo aver incluso il monitoraggio delle porte di rete, soprattutto se si seleziona la maggior parte delle porte attive disponibili nel dispositivo. Pertanto, per ottenere prestazioni migliori, è consigliabile usare server di gestione dedicati in pool di risorse dedicati per il monitoraggio della rete. Inoltre, i server di gestione membri di questo pool devono essere rimossi dai pool Tutti i server di gestione, le notifiche e le assegnazioni di Active Directory.

Il monitoraggio linux/UNIX in Operations Manager può essere assegnato a un pool di risorse dedicato, se necessario, per abilitare il monitoraggio a disponibilità elevata e la gestione degli agenti, ma non è necessario. 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, ogni server di gestione nel pool di risorse deve avere 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 è più disponibile, gli altri server di gestione non saranno in grado di considerare attendibili i certificati firmati dal server che non è riuscito.

Passaggi successivi

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