Pianificare la progettazione di un gruppo di gestione

Panoramica

Un gruppo di gestione viene identificato da un singolo database operativo, da uno o più server di gestione e da uno o più agenti e dispositivi monitorati. La connessione dei gruppi di gestione consente di visualizzare e modificare avvisi e altri dati di monitoraggio da una singola console. Le attività possono essere avviate anche da un gruppo di gestione locale da eseguire sugli oggetti gestiti di un gruppo di gestione connesso.

L'implementazione più semplice di Operations Manager è un singolo gruppo di gestione. Ogni gruppo aggiuntivo richiede almeno il proprio database operativo e il server di gestione. Ogni gruppo deve anche essere gestito separatamente con le proprie impostazioni di configurazione, i Management Pack e l'integrazione con altre soluzioni di monitoraggio e Gestione dei servizi IT.

L'implementazione del gruppo di gestione distribuito costituisce la base del 99% delle distribuzioni di Operations Manager. Consente la distribuzione di funzionalità e servizi in più server per consentire scalabilità e ridondanza per alcune di queste funzionalità. Può includere tutti i ruoli del server Operations Manager e supporta il monitoraggio dei dispositivi attraverso i limiti di attendibilità usando il server gateway.

Nel seguente diagramma viene visualizzata una possibile opzione per la topologia del gruppo di gestione distribuita.

Nota

Non esiste alcuna comunicazione diretta tra la Console operatore e i database. Tutte le comunicazioni vengono indirizzate a un server di gestione specifico sulla porta TCP 5724 e quindi ai server di database che usano OLE DB su TCP 1433 o una porta definita dall'utente specificata dall'amministratore SQL durante l'installazione dell'istanza del motore di database di SQL Server. Tuttavia, esiste una comunicazione diretta tra una console di Application Diagnostics (con la console Web) e SQL Server che ospita i database operativi e del data warehouse.

Un gruppo di gestione distribuito nell'ambiente può integrarsi con Microsoft Operations Management Suite (OMS) e usando Log Analytics, è possibile correlare, visualizzare e agire ulteriormente su prestazioni, eventi e avvisi. Ciò offre una maggiore visibilità grazie alla possibilità di eseguire ricerche personalizzate nell'intero set di dati per correlare i dati tra sistemi e applicazioni, ospitati in locale o nel cloud.

L'integrazione con Operations Manager si estende ad altri prodotti, ad esempio BMC Remedy, IBM, Netcool o altre soluzioni di gestione aziendale usate dall'organizzazione. Per altre informazioni sulla pianificazione dell'interoperabilità con queste soluzioni, vedere Integrazione con altre soluzioni di gestione.

Componenti del gruppo di gestione

Server di gestione

In Operations Manager 2007, il server di gestione radice (RMS) era un tipo specializzato di server di gestione in un gruppo di gestione ed era il primo server di gestione installato in un gruppo di gestione. RMS era il punto focale per amministrare la configurazione del gruppo di gestione, amministrare e comunicare con gli agenti e comunicare con il database operativo e altri database nel gruppo di gestione. RMS funge anche da destinazione per la console operatore e come destinazione preferita per le console Web. In System Center 2012 R2 - Operations Manager il ruolo del server di gestione radice è stato rimosso e tutti i server di gestione sono ora peer. Questa configurazione continua a esistere in System Center 2016 e versioni successive - Operations Manager.

RMS non è più un singolo punto di errore perché tutti i server di gestione ospitano i servizi ospitati in precedenza solo da RMS. I ruoli vengono distribuiti a tutti i server di gestione. Se un server di gestione non è disponibile, automaticamente ne vengono ridistribuite le responsabilità. Un ruolo di emulatore RMS fornisce compatibilità per le versioni precedenti dei Management Pack destinati all'RMS. Se non si dispone di Management Pack destinati in precedenza a RMS, non sarà necessario usare l'emulatore RMS.

Il gruppo di gestione può contenere più server di gestione per offrire ulteriori capacità e disponibilità continua. Quando due o più server di gestione vengono aggiunti a un gruppo di gestione, i server di gestione diventano automaticamente parte dei tre pool di risorse predefiniti e il lavoro viene distribuito tra i membri del pool. Per i pool di risorse definiti personalizzati, i membri vengono aggiunti manualmente. In caso di guasto di un membro del pool di risorse, gli altri membri del pool di risorse prendono in consegna il suo carico di lavoro. Quando viene aggiunto un nuovo server di gestione, il nuovo server di gestione preleva automaticamente alcune delle operazioni dai membri esistenti nel pool di risorse. Per altre informazioni sul funzionamento e sulle raccomandazioni che influenzano il piano di progettazione, vedere Considerazioni sulla progettazione del pool di risorse.

Se un server di gestione non è disponibile per qualsiasi motivo, per impostazione predefinita gli agenti che si basano su di esso eseguiranno automaticamente il failover in un altro server di gestione. Quando si seleziona il numero e il posizionamento dei server di gestione, questa capacità di failover deve essere considerata se la disponibilità elevata è un requisito.

Gli agenti si connettono a un server di gestione per comunicare con tutti gli altri componenti di Operations Manager. Alcune delle operazioni eseguite da un server di gestione sono il processo di acquisizione dei dati operativi inviati dagli agenti e l'inserimento nel database operativo e nel data warehouse.

Un server di gestione tipico gestirà circa 3.000 agenti. Le prestazioni effettive del server variano in base al volume dei dati operativi raccolti; Tuttavia, i server di gestione in genere possono supportare 3.000 agenti ciascuno, anche con un volume relativamente elevato di dati operativi.

Non è previsto alcun limite per il numero massimo di server di gestione per gruppo di gestione. Tuttavia, è consigliabile usare il minor numero possibile di server di gestione dopo aver affrontato i vincoli di scalabilità, disponibilità elevata e ripristino di emergenza.

I server di gestione devono avere una buona connettività di rete al database e al data warehouse di Operations Manager perché inviano spesso grandi volumi di dati a questi archivi. In generale, queste connessioni di SQL Server utilizzano una maggiore larghezza di banda e sono più sensibili alla latenza di rete. Pertanto, tutti i server di gestione devono trovarsi nella stessa rete locale del database operativo e del database del data warehouse e non devono essere mai distribuiti in una rete di grandi aree. La latenza tra un server di gestione e un'istanza di SQL Server che ospita i database di Operations Manager deve essere inferiore a 10 millisecondi.

Server gateway

Operations Manager richiede l'autenticazione reciproca tra agenti e server di gestione prima dello scambio di informazioni tra di essi. Per maggiore protezione, il processo di autenticazione è crittografato. Quando l'agente e il server di gestione risiedono nello stesso dominio Active Directory o in domini Active Directory che hanno stabilito relazioni di trust, utilizzano i meccanismi di autenticazione Kerberos V5 forniti da Active Directory. Quando gli agenti e i server di gestione non si trovano nello stesso limite di attendibilità, è necessario usare altri meccanismi per soddisfare il requisito di autenticazione reciproca sicura.

I server gateway vengono usati quando un firewall separa gli agenti dai server di gestione o quando gli agenti si trovano in un dominio separato non attendibile. Il server gateway funge da proxy tra gli agenti e il server di gestione. Senza il server gateway, gli agenti potrebbero comunque eseguire l'autenticazione del certificato con un server di gestione, ma un certificato X.509 deve essere rilasciato e installato in ogni agente usando lo strumento MOMCertImport.exe e ognuno richiede l'accesso al server di gestione tramite il firewall. Se gli agenti si trovano nello stesso dominio del server gateway o se si trovano in un dominio attendibile, possono usare l'autenticazione Kerberos. In questo caso, solo il server gateway e i server di gestione connessi richiederanno i certificati. Ciò include il monitoraggio delle macchine virtuali in esecuzione nell'infrastruttura distribuita come servizio (IaaS) di Microsoft Azure, con Operations Manager (ovvero il monitoraggio del cloud ibrido) che non è stato aggiunto alla stessa area di autenticazione attendibile dei ruoli che supportano il gruppo di gestione di Operations Manager oppure Operations Manager in Azure IaaS (una macchina virtuale con SQL Server che ospita i database operativi e una o più macchine virtuali che ospitano il ruolo del server di gestione) e monitorano operazioni non attendibili carichi di lavoro locali.

Di seguito è riportato un esempio di monitoraggio della distribuzione di Operations Manager per le risorse IaaS di Azure.

Di seguito è riportato un esempio di distribuzione di Operations Manager ospitata in Azure IaaS.

In genere i server gateway non vengono usati per la gestione dell'utilizzo della larghezza di banda perché il volume complessivo dei dati inviati dagli agenti a un server di gestione è simile se un server gateway viene usato o meno. Lo scopo previsto di un server gateway è ridurre lo sforzo necessario per gestire i certificati per gli agenti in domini non attendibili e ridurre il numero di percorsi di comunicazione che devono essere consentiti tramite firewall.

• La presenza di più di 2.000 agenti per server gateway può influire negativamente sulla possibilità di ripristinare in caso di interruzione prolungata che impedisce al server gateway di comunicare con il server di gestione. Se sono necessari più di 2.000 agenti, è consigliabile usare più server gateway. L'alternativa, se il tempo di ripristino del server gateway è un problema, consiste nel testare il sistema per assicurarsi che il server gateway sia in grado di svuotare rapidamente la coda dopo un'interruzione prolungata tra il server gateway e il server di gestione. Inoltre, dopo aver compilato la coda in ingresso nel server gateway, i dati nella coda vengono eliminati in base alla priorità, ovvero un'interruzione prolungata del server gateway in questo scenario potrebbe comportare la perdita di dati.
• Quando sono presenti un numero elevato di agenti connessi tramite server gateway, è consigliabile usare un server di gestione dedicato per tutti i server gateway. La connessione di tutti i server gateway a un singolo server di gestione senza altri agenti connessi può velocizzare il tempo di ripristino in caso di interruzione prolungata. Il carico effettivo sul server di gestione è il numero totale di agenti che vi segnalano direttamente o tramite server gateway.
• Per impedire al server gateway di avviare la comunicazione con un server di gestione, incluso se configurato per il failover tra più server di gestione per la disponibilità elevata, lo strumento Approvazione gateway include l'argomento della riga di comando /ManagementServerInitiatesConnection. Ciò consente a Operations Manager di conformarsi ai criteri di sicurezza di un cliente quando i sistemi vengono distribuiti in una rete perimetrale o in un altro ambiente di rete e le comunicazioni possono essere avviate solo dalla Intranet.

Server della console Web

La console Web fornisce un'interfaccia al gruppo di gestione accessibile tramite un Web browser. Non dispone della funzionalità completa della Console operatore e fornisce l'accesso solo alle visualizzazioni Monitoraggio e Area di lavoro personale. La console Web consente di accedere a tutti i dati di monitoraggio e le attività che sono azioni che possono essere eseguite su computer monitorati dalla Console operatore. L'accesso ai dati nella console Web ha le stesse restrizioni dell'accesso al contenuto nella Console operatore.

Server di report

Reporting per System Center - Operations Manager è installato in SQL Server Reporting Services (supportato dalla versione di Operations Manager in uso) e l'unica configurazione valida di Reporting Services supportata da Operations Manager Reporting Services è la modalità nativa.

Nota

L'installazione di System Center Operations Manager Reporting Services integra la sicurezza dell'istanza di report SQL Services con la sicurezza basata sui ruoli di Operations Manager. Non installare altre applicazioni di Reporting Services in questa stessa istanza di SQL Server.

I componenti del server di report di Operations Manager possono essere installati nello stesso server che esegue SQL Server 2014 o 2016 Reporting Services o in un computer diverso. Per prestazioni ottimali, in particolare in un ambiente aziendale con volumi elevati, generazione di report paralleli da parte degli utenti mentre i report interattivi o pianificati vengono elaborati simultaneamente, è necessario aumentare le prestazioni per gestire più utenti simultanei e carichi di esecuzione di report più grandi. È consigliabile che Operations Manager Reporting Service non si trovi nello stesso SERVER che ospita il database del data warehouse e installato in un sistema dedicato.

Database operativo

Il database operativo è un database di SQL Server che contiene tutti i dati operativi, le informazioni di configurazione e le regole di monitoraggio per un gruppo di gestione. Il database di Operations Manager è una singola origine di errore per il gruppo di gestione, quindi può essere resa a disponibilità elevata usando configurazioni di clustering supportate.

Per mantenere il database a dimensioni coerenti, le impostazioni di pulitura in Operations Manager specificano la durata di conservazione dei dati. Per impostazione predefinita, questa durata è di sette (7) giorni.

Database del data warehouse per la creazione di report

Il data warehouse di report è un database di SQL Server che raccoglie e archivia i dati operativi per la creazione di report a lungo termine. Questi dati vengono scritti direttamente dalle regole che raccolgono dati da segnalare e dai processi di sincronizzazione dei dati nel database operativo. La manutenzione del data warehouse, inclusa l'aggregazione, la pulitura e l'ottimizzazione, viene eseguita automaticamente da Operations Manager.

Nella tabella seguente sono evidenziati i tipi di dati predefiniti e il periodo di conservazione dopo la configurazione iniziale del database del data warehouse.

Set di dati	Tipo di aggregazione	Periodo di conservazione (in giorni)
Avviso	Raw	400
Monitoraggio client	Raw	30
Monitoraggio client	Giornaliero	400
Eventi	Raw	100
Prestazioni	Raw	10
Prestazioni	Oraria	400
Prestazioni	Giornaliero	400
Provincia	Raw	180
Provincia	Oraria	400
Provincia	Giornaliero	400

Un data warehouse può servire più gruppi di gestione. Ciò consente a un singolo report di incorporare i dati di tutti i computer dell'organizzazione.

Analogamente al database di Operations Manager, il database del data warehouse può essere clusterato per la disponibilità elevata. Se non è cluster, deve essere monitorato attentamente in modo che eventuali problemi possano essere risolti rapidamente.

Agente di raccolta dati ACS

L'agente di raccolta dati ACS riceve ed elabora eventi dai server d'inoltro ACS, quindi invia tali dati al database ACS. Questa elaborazione include il disassembling dei dati in modo che possa essere distribuito in più tabelle all'interno del database ACS, riducendo al minimo la ridondanza dei dati e applicando filtri in modo che gli eventi non necessari non vengano aggiunti al database ACS.

Database ACS

Il database ACS è l'archivio centrale degli eventi generati da un criterio di controllo nell'ambito di una distribuzione ACS. Il database ACS può essere ubicato sullo stesso computer dell'agente di raccolta dei dati ACS, ma per prestazioni migliori ciascuno di essi andrebbe installato su un server dedicato. Per impostazione predefinita, i dati vengono conservati per quattordici (14) giorni.

Server d'inoltro ACS

Il servizio che esegue i server d'inoltro ACS è incluso nell'agente Operations Manager. Per impostazione predefinita, quando è installato l'agente Operations Manager il servizio è installato ma non abilitato. È possibile abilitare questo servizio per più computer agente contemporaneamente usando l'attività Abilita raccolta di controllo o powerShell. Dopo aver abilitato tale servizio, tutti gli eventi di protezione vengono inviati all'agente di raccolta dati ACS per essere aggiunti al registro di protezione locale.

Considerazioni relative alla progettazione

Quando si decide di implementare un singolo o più gruppi di gestione, è necessario prendere in considerazione i fattori seguenti:

• Maggiore capacità. Operations Manager non prevede limiti predefiniti relativi al numero di agenti che un singolo gruppo di gestione può supportare. A seconda dell'hardware usato e del carico di monitoraggio (più Management Pack distribuiti significa un carico di monitoraggio più elevato) nel gruppo di gestione, potrebbero essere necessari più gruppi di gestione per mantenere prestazioni accettabili.
• Viste consolidate. Quando vengono usati più gruppi di gestione per monitorare un ambiente, è necessario un meccanismo per fornire una visualizzazione consolidata dei dati di monitoraggio e avviso da essi contenuti. Questa operazione può essere eseguita distribuendo un gruppo di gestione aggiuntivo (che potrebbe avere o meno responsabilità di monitoraggio) che ha accesso a tutti i dati in tutti gli altri gruppi di gestione. Questi gruppi di gestione vengono quindi considerati connessi. Il gruppo di gestione usato per fornire una visualizzazione consolidata dei dati è denominato gruppo di gestione locale e gli altri che forniscono dati sono denominati gruppi di gestione connessi.
• Sicurezza e amministrazione. Il partizionamento dei gruppi di gestione per motivi di sicurezza e amministrativi è simile al concetto di delega dell'autorità amministrativa su unità organizzative o domini di Active Directory in gruppi amministrativi diversi. L'azienda può includere più gruppi IT, ognuno con la propria area di responsabilità. L'area potrebbe essere un'area geografica specifica o una divisione aziendale. Ad esempio, nel caso di una società holding, può essere una delle società controllate. Se esiste questo tipo di delega completa dell'autorità amministrativa dal gruppo IT centralizzato, potrebbe essere utile implementare una struttura del gruppo di gestione in ognuna delle aree. Possono quindi essere configurati come gruppi di gestione connessi a un gruppo di gestione locale che risiede nel data center IT centralizzato.
• Lingue installate. Tutti i server con un ruolo del server Operations Manager installato in tali server devono essere installati nella stessa lingua. Ciò significa che non è possibile installare il server di gestione usando la versione inglese di Operations Manager 2012 R2 e quindi distribuire la Console operatore usando la versione giapponese. Se il monitoraggio deve estendersi su più lingue, sarà necessario un gruppo di gestione aggiuntivo per ogni lingua degli operatori.
• Funzionalità di produzione e preproduzione. In Operations Manager è consigliabile disporre di un'implementazione di produzione usata per monitorare le applicazioni di produzione e un'implementazione di preproduzione con un'interazione minima con l'ambiente di produzione. Il gruppo di gestione della preproduzione viene usato per il test e l'ottimizzazione delle funzionalità del Management Pack prima della migrazione nell'ambiente di produzione. Inoltre, alcune aziende usano un ambiente di gestione temporanea per i server in cui i server appena compilati vengono inseriti per un periodo di burn-in prima di essere inseriti nell'ambiente di produzione. Il gruppo di gestione della preproduzione può essere usato per monitorare l'ambiente di gestione temporanea per garantire l'integrità dei server prima dell'implementazione di produzione.
• Funzionalità ACS dedicate. Se i requisiti includono la necessità di raccogliere gli eventi del registro di sicurezza di Windows Audit o gli eventi di sicurezza UNIX/Linux, si implementerà il servizio di raccolta di controllo di controllo. Può essere utile implementare un gruppo di gestione che supporti la funzione ACS esclusivamente se i requisiti di sicurezza dell'azienda impongono che la funzione ACS sia controllata e gestita da un gruppo amministrativo diverso da quello che gestisce il resto dell'ambiente di produzione.
• Funzionalità di ripristino di emergenza. In Operations Manager tutte le interazioni con il database di Operations Manager vengono registrate nei log delle transazioni prima di essere sottoposte a commit nel database. Questi log delle transazioni possono essere inviati a un altro server che esegue Microsoft SQL Server ed è stato eseguito il commit in una copia del database di Operations Manager. Questa funzionalità è un'opzione per garantire la ridondanza del database operativo di Operations Manager tra due server SQL nello stesso gruppo di gestione. Quando è necessario eseguire un failover controllato, i server di gestione nel gruppo di gestione richiedono una modifica del Registro di sistema per fare riferimento e comunicare con SQL Server secondario. È possibile distribuire un gruppo di gestione di failover, che corrisponde alla configurazione esatta del gruppo di gestione primario (Management Pack, override, sottoscrizioni di notifica, sicurezza e così via) e gli agenti sono configurati per segnalare a entrambi i gruppi di gestione. Se l'intero gruppo di gestione primario diventa non disponibile per qualsiasi motivo, non è previsto alcun tempo di inattività dell'ambiente di monitoraggio. Questa soluzione garantisce la continuità del servizio del gruppo di gestione e la perdita zero del monitoraggio operativo.

Prima di distribuire System Center Operations Manager in un ambiente di produzione, pianificare la progettazione del gruppo di gestione. Durante la fase di pianificazione, comprendere i componenti del servizio IT (ovvero l'infrastruttura e il livello applicazione) e il numero di sistemi e dispositivi che li supportano, come si integreranno e supporteranno i processi di gestione degli eventi imprevisti e dei problemi e come verranno visualizzati i dati per diversi livelli di supporto per escalation degli eventi imprevisti, progettazione, consumer di servizi e gestione.

Gruppi di gestione connessi

Molte aziende con server in più posizioni geografiche richiedono il monitoraggio centrale di tali server. La configurazione del gruppo di gestione connesso, illustrata nell'immagine seguente, è un set di processi del flusso di lavoro progettati per creare un'infrastruttura di gestione dei sistemi gerarchica.

Questa configurazione può essere usata per ottenere il monitoraggio centralizzato. È progettato per supportare la visualizzazione degli avvisi e dei dati di monitoraggio e per avviare attività su un oggetto gestito di un gruppo di gestione connesso.

Connettendo i gruppi di gestione di Operations Manager, è possibile gestire le funzionalità di monitoraggio centralizzate contemporaneamente abilitando:

• Monitoraggio di un numero maggiore di oggetti di gestione di quanto sia possibile con un singolo gruppo di gestione.
• Isolamento dell'attività di monitoraggio in base alle business unit logiche, ad esempio "Marketing" o località fisiche, ad esempio Roma.

La connessione di gruppi di gestione non implica la distribuzione di nuovi server. Con questa operazione si consente invece al gruppo di gestione locale di accedere agli avvisi e alle informazioni di individuazione presenti in un gruppo di gestione connesso. In tal modo, è possibile visualizzare e interagire con tutti gli avvisi e con gli altri dati di monitoraggio da più gruppi di gestione in un'unica Console operatore. È inoltre possibile eseguire attività sui computer monitorati dei gruppi di gestione connessi. Per informazioni su come connettere i gruppi di gestione, vedere Connessione di gruppi di gestione in Operations Manager.

Lingue installate

I gruppi di gestione di Operations Manager supportano una sola lingua installata. Se nell'ambiente IT complessivo da monitorare sono installate più lingue, è necessario creare un gruppo di gestione distinto per ogni lingua.