Disponibilità elevata e ripristino di emergenza

System Center : i server e le funzionalità di Operations Manager possono potenzialmente avere esito negativo, con effetti sulle funzionalità di Operations Manager. La quantità di dati e le funzionalità perse in caso di errore variano a seconda dello scenario di errore. Dipende dal ruolo della funzionalità con errori e dal tempo necessario per recuperare la funzionalità con errori.

Disponibilità elevata

Le esigenze di disponibilità elevata vengono risolte creando ridondanza nel gruppo di gestione per i database operativi e del data warehouse di Operations Manager, i server gateway e di gestione e carichi di lavoro specifici. Questi carichi di lavoro includono il monitoraggio dei dispositivi di rete, il monitoraggio multipiattaforma e i carichi di lavoro specifici del gruppo di gestione gestiti in precedenza dal server di gestione radice.

La configurazione di più server, un singolo gruppo di gestione può usare SQL Server Always On per garantire disponibilità elevata e continuità del servizio dei database di Operations Manager. La tolleranza di errore del server di gestione viene fornita con almeno due server di gestione e usando i pool di risorse per il monitoraggio di server UNIX, server Linux e dispositivi di rete. I server Windows basati su agente possono essere configurati con un server di gestione primario e secondario per reindirizzare le comunicazioni degli agenti in caso di errore di un server di gestione.

L'emulatore RMS può essere spostato in un altro server di gestione, anche se il server di gestione che ospita l'emulatore RMS non sarà più disponibile.

Le connessioni della Console operatore possono essere rese a disponibilità elevata configurando la disponibilità elevata per i servizi di accesso ai dati. A tale scopo, è possibile installare Bilanciamento carico di rete Microsoft o usare un servizio di bilanciamento del carico basato su hardware o un alias DNS. Uno o più server di gestione vengono aggiunti come membri del pool di bilanciamento carico di rete e quando si apre la console si fa riferimento al nome virtuale registrato in DNS, dei server di gestione con bilanciamento del carico.

È possibile distribuire più server gateway in un confine di trust per fornire i percorsi ridondanti per gli agenti che si trovano oltre il confine di trust. Oltre a eseguire il failover tra un server di gestione primario e uno o più server di gestione secondari, gli agenti possono anche eseguire il failover tra server gateway. È inoltre possibile utilizzare più server gateway per distribuire il carico di lavoro della gestione dei computer gestiti senza agente e dei dispositivi di rete gestita.

Oltre a fornire ridondanza tramite il failover agente-gateway, i server gateway possono essere configurati per eseguire il failover tra i server di gestione in un gruppo di gestione se sono disponibili più server di gestione.

Anche se SQL Server Reporting Services supporta un modello di distribuzione con scalabilità orizzontale che consente di eseguire più istanze del server di report che condividono un singolo database del server di report, non è supportato con Operations Manager. Operations Manager Reporting installa un'estensione di sicurezza personalizzata come parte della configurazione dei componenti front-end, che non possono essere replicati nella Web farm.

Ripristino di emergenza

Il ripristino di emergenza è correlato alle misure adottate per garantire che le operazioni possano essere riprese in caso di errore irreversibile, ad esempio la perdita dell'intero data center che ospita l'infrastruttura primaria. È un elemento importante che deve essere considerato in qualsiasi distribuzione; le decisioni prese nella pianificazione del ripristino di emergenza influiscono sul modo in cui Operations Manager potrà continuare a supportare il monitoraggio proattivo e il reporting delle prestazioni e della disponibilità dei servizi IT critici. Questa sezione si concentrerà sulla strategia di ripristino di emergenza e resilienza consigliata e sui passaggi da eseguire per garantire un ripristino senza problemi.

Sebbene le soluzioni a disponibilità elevata e ripristino di emergenza forniscano protezione da errori di sistema o perdita di sistema, non devono essere basate sulla protezione da perdite o danneggiamenti accidentali, imprevisti o dannosi. In questi casi, potrebbe essere necessario eseguire il backup di copie di replica copiate o ritardate per le operazioni di ripristino. In molti casi, un'operazione di ripristino è la forma più appropriata di ripristino di emergenza. Un esempio di questo potrebbe essere un database di report o dati di analisi con priorità bassa. In molti casi, il costo per abilitare il ripristino di emergenza multisito a livello di sistema o applicazione supera notevolmente il valore dei dati. Nei casi in cui il valore a breve termine dei dati è basso e la necessità di accedere ai dati può essere ritardata senza gravi conseguenze aziendali se un errore o un ripristino di emergenza del sito eccessivo, prendere in considerazione l'uso di semplici processi di backup e ripristino per il ripristino di emergenza se il risparmio sui costi lo giustifica.

Comprendere l'impatto e la tolleranza per i tempi di inattività consente di prendere decisioni che devono essere comprese per progettare correttamente l'architettura per Operations Manager e il livello di complessità e costi necessari per supportare il ripristino di emergenza. Considerare inoltre l'entità del monitoraggio della perdita dei dati che l'organizzazione IT può tollerare senza causare conseguenze aziendali. Questo è descritto meglio in due termini: obiettivo del tempo di ripristino (RTO) e obiettivo del punto di ripristino (RPO).

Le due configurazioni di progettazione di ripristino di emergenza più comuni per Operations Manager sono:

• Creazione di un gruppo di gestione duplicato distribuito nel data center secondario che duplica la scalabilità e la configurazione del gruppo di gestione primario.
• Distribuzione di server aggiuntivi in un data center secondario per supportare il database operativo e del data warehouse con i server di gestione distribuiti in una configurazione cold standby, non partecipando al gruppo di gestione fino a quando non è necessario eseguire le azioni di ripristino.

La distribuzione di un gruppo di gestione duplicato è un'opzione quando non c'è tolleranza per i tempi di inattività; tuttavia, è l'opzione più complessa. La configurazione tra entrambi deve essere coerente in modo che, quando si esegue il cut over, non c'è alcuna differenza in ciò che viene monitorato, segnalato o segnalato, presentato e infine inoltrato. L'integrazione con altre piattaforme di monitoraggio o piattaforme ITSM, ad esempio System Center - Service Manager, Remedy o ServiceNow, dovrà esistere anche e possibilmente configurata in uno stato attivo/passivo per evitare la duplicazione di eventi imprevisti, elementi di configurazione e così via. Gli agenti verranno multihomed tra entrambi i gruppi di gestione, quindi ci sarà la duplicazione dei dati.

Il diagramma seguente è un esempio di questo scenario di progettazione.

Se il ripristino immediato non è necessario per la distribuzione di Operations Manager e si vuole evitare la complessità di un gruppo di gestione duplicato, in alternativa è possibile distribuire componenti aggiuntivi del gruppo di gestione nel data center secondario per mantenere la funzionalità del gruppo di gestione. È consigliabile implementare almeno un gruppo di disponibilità AlwaysOn di SQL Server 2014 o 2016 per fornire il ripristino dei database operativi e del data warehouse tra due o più data center, in cui un'istanza del cluster di failover a due nodi viene distribuita nel data center primario e un'istanza autonoma di SQL Server nel data center secondario come parte di un singolo cluster di failover di Windows Server (WSFC). La replica secondaria per il gruppo di disponibilità AlwaysOn si trova nell'istanza autonoma non fcI, come illustrato nel diagramma seguente.

In questo esempio sarebbe necessario distribuire uno o più server Windows con la stessa configurazione hardware e lo stesso nome computer e reinstallare il ruolo del server di gestione usando il parametro /Recover . Di seguito è riportato un esempio:

Setup.exe /silent /AcceptEndUserLicenseAgreement:1 /recover /InstallPath:<Install Directory> /ManagementGroupName:MGNAME /SqlServerInstance:SQLServerName.domain.com /DatabaseName:OperationsManager /DWSqlServerInstance:SQLServerName.domain.com /DWDatabaseName:OperationsManagerDW /ActionAccountUser:DOMAIN\omaa /ActionAccountPassword:password /DASAccountUser:DOMAIN\omdas /DASAccountPassword:password /DatareaderUser:DOMAIN\omdr /DatareaderPassword:password /DataWriterUser:DOMAIN\omdw /DataWriterPassword:password /EnableErrorReporting:Always /SendCEIPReports:1 /UseMicrosoftUpdate:0

Per altre informazioni, vedere Installazione di Operations Manager dal prompt dei comandi.

Durante questo periodo, gli agenti accoderanno i dati raccolti (avvisi, eventi, prestazioni e così via) fino a quando non potranno riprendere la comunicazione con un server di gestione nel gruppo di gestione. Questo approccio evita l'installazione di nuove istanze di SQL Server e il ripristino dei database dall'ultimo backup valido noto. In questo scenario di ripristino, tuttavia, è probabile che si verifichi un ritardo più lungo nel tornare a uno stato operabile, dato che sarà necessario distribuire gli altri ruoli necessari per riprendere la funzionalità di monitoraggio minima. Se questo approccio non è accettabile, è possibile distribuire i server di gestione nel data center secondario per il ripristino in standby. Rimuoverli come membri dei tre pool di risorse primari: tutti i server di gestione pool di risorse, le notifiche e l'assegnazione di Active Directory. Ciò include anche qualsiasi pool di risorse personalizzato, che può includere i server di gestione ospitati nel data center primario e deve continuare a funzionare come parte del piano di ripristino. I servizi System Center Data Access, System Center Configuration Management e Microsoft Monitoring Agent devono essere arrestati e impostati su manuale o disabilitato e avviati solo in uno scenario di ripristino di emergenza.

Se un server di gestione supporta l'integrazione (tramite un connettore ospitato direttamente nel server di gestione o da un altro prodotto System Center, ad esempio VMM, Orchestrator o Service Manager), sarà necessario pianificare questa operazione per i passaggi di ripristino manuali o automatici a seconda della configurazione di integrazione e della sequenza di passaggi di ripristino. In questo modo, qualsiasi altra dipendenza dal server di gestione viene acquisita e pianificata quando è necessario implementare il piano di ripristino di emergenza.

Se un sito passa offline, l'agente eseguirà il failover al server di gestione in un altro sito, presupponendo che la configurazione di failover dell'agente consenta questa operazione. Riconfigurare gli agenti Windows per memorizzare nella cache solo i server di gestione nel data center primario che devono gestirli per impedire loro di tentare di eseguire il failover in un server di gestione nel data center secondario, che ritarderebbe solo il ripristino e la creazione di report. Questa operazione può essere eseguita se si distribuisce manualmente l'agente in modo automatizzato con uno script (ad esempio, VBScript o, meglio ancora, PowerShell) per preconfigurare durante l'installazione o dopo la distribuzione se si esegue il push dell'agente dalla console, usando di nuovo un metodo con script gestito con la soluzione di gestione della configurazione aziendale.

Operations Manager può essere distribuito in macchine virtuali di Azure come opzione alternativa di ripristino di emergenza per mantenere la continuità del gruppo di gestione. Sarà necessario distribuire ANCHE SQL Server in una macchina virtuale in Azure e non in una configurazione ibrida, perché la latenza tra un server di gestione e SQL Server che ospita i database di Operations Manager influirà negativamente sulle prestazioni del gruppo di gestione.

Prendere in considerazione l'ambito di monitoraggio, la topologia di rete e la connettività di rete a Microsoft Azure (ovvero VPN da sito a sito o ExpressRoute), i punti di integrazione (ovvero soluzioni ITSM, altri prodotti System Center, componenti aggiuntivi di terze parti e così via), l'accesso alla console, le leggi o i criteri pertinenti e così via per progettare correttamente questo scenario all'interno di Azure IaaS o di altri provider di servizi cloud pubblici.