Pianificazione della progettazione di un gruppo di gestione

Importante

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

Panoramica

Un gruppo di gestione è identificato da un singolo database operativo, da uno o più server di gestione e da uno o più agenti e dispositivi monitorati. La connessione di più gruppi di gestione consente di visualizzare e modificare avvisi e altri dati di monitoraggio da una singola console. Da un gruppo di gestione locale si possono anche avviare attività da eseguire sugli oggetti gestiti di un gruppo di gestione collegato.

L'implementazione più semplice di Operations Manager è un singolo gruppo di gestione. Ogni gruppo aggiuntivo richiede almeno un proprio database operativo e server di gestione. Ciascun gruppo deve anche essere gestito separatamente con le proprie impostazioni di configurazione, i propri Management Pack e la propria integrazione con altre soluzioni ITSM e di monitoraggio.

L'implementazione distribuita dei gruppi di gestione è alla base del 99% delle distribuzioni di Operations Manager. Consente la distribuzione di funzionalità e servizi su più server per assicurare scalabilità e ridondanza ad alcune di tali funzionalità. Può includere tutti i ruoli del server di Operations Manager e supporta il monitoraggio dei dispositivi tra 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 inviate a un server di gestione specifico tramite la porta TCP 5724 e quindi ai server di database tramite OLE DB sulla porta TCP 1433 o un'altra porta definita dall'utente specificata dall'amministratore SQL durante la configurazione dell'istanza del motore di database di SQL Server. Tuttavia, esiste una comunicazione diretta tra una console di Diagnostica applicazione (con la console Web) e la SQL Server che ospita i database operativi e del data warehouse.

Un gruppo di gestione distribuito nell'ambiente può essere integrato con Microsoft Operations Management Suite (OMS) e usando Log Analytics, è possibile correlare, visualizzare e agire ulteriormente sulle prestazioni, sugli eventi e sugli avvisi. In questo modo è possibile aumentare la visibilità eseguendo 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 è estesa ad altri prodotti, ad esempio BMC Remedy, IBM, Netcool o altre soluzioni per la gestione aziendale in uso nell'organizzazione. Per altre informazioni sulla pianificazione dell'interoperabilità con queste soluzioni, vedere Integration with other management solutions (Integrazione con altre soluzioni di gestione).

Componenti del gruppo di gestione

Server di gestione

In Operations Manager 2007 il server di gestione radice (RMS, Root Management Server) è un tipo specializzato di server di gestione in un gruppo di gestione ed è il primo server di gestione installato in un gruppo di gestione. Il server RMS ha un ruolo centrale nell'amministrare la configurazione del gruppo di gestione, nel gestire gli agenti e nel comunicare con essi. Riveste inoltre un ruolo importante nel comunicare con il database operativo e con gli altri database del gruppo di gestione. Il server RMS funge anche da destinazione della Console operatore e da destinazione preferita delle 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 peer. Questa configurazione è ancora presente in System Center - Operations Manager versione 2016 e successive.

Il server RMS non è più un singolo punto di errore perché tutti i server di gestione ospitano i servizi precedentemente ospitati solo dal server 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, tali server diventano automaticamente parte dei tre pool di risorse predefiniti e il lavoro viene distribuito tra i membri del pool. Per i pool di risorse 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 seleziona automaticamente alcune delle operazioni dei membri esistenti nel pool di risorse. Esaminare le considerazioni sulla progettazione del pool di risorse per altre informazioni su come funzionano e sulle raccomandazioni che influiscono sul piano di progettazione.

Se per qualsiasi motivo un server di gestione non è disponibile, gli agenti che si basano su di esso eseguiranno automaticamente il failover su un altro server di gestione per impostazione predefinita. Quando si selezionano il numero e la posizione dei server di gestione, se la disponibilità elevata è un requisito, è necessario prendere in considerazione questa possibilità di failover.

Gli agenti si connettono a un server di gestione per comunicare con tutti gli altri componenti di Operations Manager. Parte del lavoro eseguito da un server di gestione è costituito dall'acquisizione dei dati operativi inviati dagli agenti e dall'inserimento di tali dati nel database operativo e in quello del data warehouse.

Un server di gestione tipico gestisce approssimativamente 3000 agenti. Le prestazioni effettive del server variano in base al volume dei dati operativi raccolti. I server di gestione, tuttavia, possono in genere supportare 3000 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 vincoli di scalabilità, disponibilità elevata e ripristino di emergenza.

I server di gestione devono avere una buona connettività di rete con il data warehouse e il database di Operations Manager, poiché inviano spesso ingenti volumi di dati a questi archivi. In linea di massima, queste connessioni SQL Server utilizzano più larghezza di banda e sono più sensibili alla latenza di rete. Tutti i server di gestione devono quindi trovarsi nella stessa rete locale del database operativo e di quello del data warehouse e non devono mai essere distribuiti su una rete WAN. La latenza tra un server di gestione e un'istanza di SQL Server che ospita i database di Operations Manager deve essere inferiore ai 10 millisecondi.

Server gateway

Operations Manager richiede l'esecuzione dell'autenticazione reciproca tra agenti e server di gestione prima dello scambio di informazioni tra questi due tipi di componenti. 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 all'interno dello 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 possono ancora eseguire l'autenticazione del certificato con un server di gestione, ma sarà necessario emettere un certificato X.509 e installarlo in ogni agente con lo strumento MOMCertImport.exe. Ogni agente dovrà quindi richiedere l'accesso al server di gestione attraverso il firewall. Se gli agenti si trovano nello stesso dominio del server gateway o in un dominio trusted, possono usare l'autenticazione Kerberos. In questo caso, i certificati saranno necessari solo per il server gateway e per i server di gestione connessi. Ciò include il monitoraggio delle macchine virtuali in esecuzione nell'infrastruttura di Microsoft Azure come servizio (IaaS), con Operations Manager (ovvero il monitoraggio cloud ibrido) che non è aggiunto alla stessa area di autenticazione attendibile dei ruoli che supportano il gruppo di gestione di Operations Manager o che è stata distribuita in Azure IaaS (una macchina virtuale con SQL Server hosting dei database operativi e di una o più macchine virtuali che ospitano il ruolo del server di gestione e monitorano carichi di lavoro locali non attendibili.

La figura seguente mostra una distribuzione di Operations Manager di esempio che esegue il monitoraggio di risorse Azure IaaS.

La figura seguente mostra una distribuzione di Operations Manager di esempio 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 di 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.

• Avere più di 2.000 agenti per server gateway può influire negativamente sulla possibilità di ripristinare in caso di interruzione sostenuta che impedisce al server gateway di comunicare con il server di gestione. Se sono necessari più di 2000 agenti, è consigliabile disporre di più server gateway. L'alternativa, se il tempo di ripristino del server gateway è un problema, è testare il sistema per garantire 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 che la coda in ingresso del server gateway è riempita, i dati presenti in tale coda vengono eliminati in base alla priorità. Questo significa che in questo scenario un guasto prolungato del server gateway può determinare una perdita di dati.
• Se è presente un numero elevato di agenti collegati tramite server gateway, è consigliabile usare per tutti i server gateway un server di gestione dedicato. 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 di lavoro effettivo del server di gestione corrisponde al numero totale di agenti collegati a esso direttamente o tramite server gateway.
• Per impedire al server gateway di avviare la comunicazione con un server di gestione, incluso quando configurato per eseguire il failover tra più server di gestione per la disponibilità elevata, lo strumento Approvazione gateway include l'argomento della riga di comando /ManagementServerInitiatesConnection. Questo consente a Operations Manager di conformarsi ai criteri di sicurezza del cliente quando i sistemi sono distribuiti in una rete perimetrale o in un altro ambiente di rete e la comunicazione può essere avviata solo dalla rete intranet.

Server della console Web

La console Web offre al gruppo di gestione un'interfaccia a cui è possibile accedere 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 fornisce l'accesso a tutti i dati e le attività di monitoraggio, a condizione che si tratti di azioni che possono essere eseguite su computer monitorati dalla Console operatore. L'accesso ai dati nella console Web presenta le stesse limitazioni dell'accesso al contenuto nella Console operatore.

Server di report

Creazione di report 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 è la modalità nativa.

Nota

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

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

Database operativo

Il database operativo è un database SQL Server in cui sono archiviati tutti i dati operativi, le informazioni sulla configurazione e le regole di monitoraggio di un gruppo di gestione. Il database di Operations Manager è un'unica origine di errore per il gruppo di gestione e può essere reso a disponibilità elevata mediante configurazioni di cluster supportate.

Per mantenere le dimensioni del database a un livello accettabile, le impostazioni di pulitura di Operations Manager devono indicare per quanto tempo i dati possono rimanere nel database. Per impostazione predefinita, la durata è sette (7) giorni.

Database del data warehouse per reporting

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

La tabella seguente mostra 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	Notifica non elaborata	400
Monitoraggio client	Notifica non elaborata	30
Monitoraggio client	Ogni giorno	400
evento	Notifica non elaborata	100
Prestazioni	Notifica non elaborata	10
Prestazioni	Ogni ora	400
Prestazioni	Ogni giorno	400
State	Notifica non elaborata	180
State	Ogni ora	400
State	Ogni giorno	400

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

Analogamente al database di Operations Manager, il database del data warehouse può essere organizzato in cluster per assicurare disponibilità elevata. Se non è in 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 possano essere distribuiti 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 mantenuti per quattordici (14) giorni.

Servizio di 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 il servizio su più computer agente contemporaneamente usando l'attività Enable Audit Collection (Abilita raccolta dati di controllo) oppure mediante 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 gruppo o più gruppi di gestione, è necessario prendere in considerazione i fattori seguenti:

• Maggiore capacità. Operations Manager non ha limiti predefiniti riguardo al numero di agenti che può essere supportato da un singolo gruppo di gestione. A seconda dell'hardware in uso e del carico di monitoraggio nel gruppo di gestione (un numero elevato di Management Pack distribuiti corrisponde a un maggiore carico di monitoraggio), per mantenere un livello di prestazioni accettabile può essere necessario disporre di più gruppi di gestione.
• Visualizzazioni consolidate. Se per monitorare un ambiente vengono usati diversi gruppi di gestione, è necessario definire un meccanismo che offra una visualizzazione consolidata dei dati di monitoraggio e avviso provenienti da tali gruppi. A questo proposito è possibile distribuire un gruppo di gestione aggiuntivo con accesso a tutti i dati di tutti gli altri gruppi di gestione e che può avere o meno responsabilità di monitoraggio. Questi gruppi di gestione vengono chiamati gruppi connessi. Il gruppo di gestione usato per offrire una visualizzazione consolidata dei dati è chiamato gruppo di gestione locale, mentre gli altri gruppi che forniscono dati a quest'ultimo sono chiamati 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 a gruppi amministrativi diversi. Un'azienda può includere diversi gruppi IT, ciascuno con la propria area di responsabilità. Il termine "area" può indicare una regione geografica o un reparto aziendale. Nel caso di una società finanziaria, ad esempio, può trattarsi di una delle filiali. Se è stato messo in atto questo tipo di delega completa dell'autorità amministrativa del gruppo IT centralizzato, può essere utile implementare una struttura di gruppi di gestione in ciascuna delle aree. Questi gruppi possono essere configurati come gruppi di gestione connessi a un gruppo di gestione locale che si trova nel data center IT centralizzato.
• Lingue installate. Tutti i server su cui è installato un ruolo server di Operations Manager devono essere configurati 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 le attività di monitoraggio riguardano ambienti con lingue diverse, è necessario aggiungere un gruppo di gestione distinto per ciascuna lingua degli operatori.
• Funzionalità di produzione e preproduzione. In Operations Manager è consigliabile avere un'implementazione di produzione usata per il monitoraggio delle applicazioni di produzione e un'implementazione di preproduzione con interazione minima con l'ambiente di produzione. Il gruppo di gestione di preproduzione viene usato per testare e ottimizzare le funzionalità del Management Pack prima della migrazione nell'ambiente di produzione. Alcune aziende, inoltre, usano un ambiente di gestione temporanea in cui i server appena creati vengono posizionati per un periodo di burn-in prima dell'inserimento in produzione. Il gruppo di gestione di preproduzione può essere usato per monitorare l'ambiente di gestione temporanea per garantire l'integrità dei server prima dell'implementazione di produzione.
• Funzionalità ACS dedicata. Se i requisiti includono la necessità di raccogliere eventi del log di sicurezza di Windows Audit o eventi di sicurezza UNIX/Linux, si implementerà il servizio di raccolta di controllo. Se i requisiti di sicurezza dell'azienda impongono che la funzione ACS sia controllata e amministrata da un gruppo amministrativo diverso da quello che gestisce il resto dell'ambiente di produzione, può essere utile implementare un gruppo di gestione che supporti in modo esclusivo la funzione ACS.
• Funzionalità di ripristino di emergenza. In Operations Manager tutte le interazioni con il database di Operations Manager vengono registrate in log delle transazioni prima del 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à consente di fornire la ridondanza del database operativo di Operations Manager tra due istanze di SQL Server nello stesso gruppo di gestione. Quando è necessario eseguire un failover controllato, i server di gestione presenti nel gruppo di gestione richiedono una modifica del Registro di sistema per fare riferimento e comunicare con l'istanza di SQL Server secondaria. È 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 non è più disponibile per qualsiasi motivo, non si verifica alcun tempo di inattività dell'ambiente di monitoraggio. Questa soluzione assicura la continuità del servizio del gruppo di gestione e la totale assenza di interruzioni 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 infrastruttura e a livello di 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 di escalation degli eventi imprevisti, progettazione, consumer di servizi e gestione.

Gruppi di gestione connessi

Molte aziende con server installati in diverse località geografiche devono poter disporre di un sistema di monitoraggio centralizzato di tali server. La configurazione del gruppo di gestione connesso, mostrata nella figura seguente, è un insieme di processi del flusso di lavoro progettati per creare un'infrastruttura gerarchica di gestione dei sistemi.

È possibile usare questa configurazione per implementare un monitoraggio centralizzato. È progettato per supportare la visualizzazione di avvisi e dati di monitoraggio e per avviare attività su un oggetto gestito di un gruppo di gestione connesso.

Collegando i gruppi di gestione di Operations Manager è possibile mantenere la funzionalità di monitoraggio centralizzato ottenendo al tempo stesso i risultati seguenti:

• Monitoraggio di un numero maggiore di oggetti gestiti rispetto a un singolo gruppo di gestione.
• Isolamento dell'attività di monitoraggio in base a unità di lavoro logiche, ad esempio Marketing, oppure in base a ubicazioni fisiche, ad esempio Roma.

Quando si connettono gruppi di gestione, non si distribuiscono nuovi server; invece, si consente al gruppo di gestione locale di avere accesso 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 sulla connessione di gruppi di gestione, vedere Connessione di gruppi di gestione in Operations Manager.

Lingue installate

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