Condividi tramite

Considerazioni sulla progettazione di SQL Server

  • Articolo

System Center Operations Manager si basa su Microsoft SQL Server per supportare i database di controllo operativi, data warehouse e ACS. Questi database sono essenziali e vengono creati durante la distribuzione del primo server di gestione o agente di raccolta dati ACS nel gruppo di gestione.

In un ambiente lab o in una distribuzione su scala ridotta di Operations Manager, SQL Server può essere inserito nel primo server di gestione del gruppo di gestione.

In una distribuzione distribuita su scala media e aziendale, l'istanza di SQL Server deve trovarsi in un server autonomo dedicato o in una configurazione a disponibilità elevata di SQL Server. In entrambi i casi, SQL Server deve esistere già ed è accessibile prima di avviare l'installazione del primo server di gestione o dell'agente di raccolta dati ACS.

Non è consigliabile usare i database di Operations Manager da un'istanza di SQL con altri database dell'applicazione per evitare potenziali problemi con I/O e altre restrizioni relative alle risorse hardware.

Importante

Operations Manager non supporta istanze PaaS (Platform as a Service) di SQL, inclusi prodotti come Istanza gestita di SQL di Azure o Amazon Relational Database Service (AWS RDS). Usare un'istanza di SQL Server installata in un computer Windows. L'unica eccezione è all'interno del Istanza gestita SCOM di Monitoraggio di Azure, che usa l'istanza gestita di SQL di Azure e non è riconfigurabile.

requisiti di SQL Server

Le versioni seguenti di SQL Server Enterprise & edizione Standard sono supportate per un'installazione esistente della versione di System Center Operations Manager per ospitare reporting server, operativo, data warehouse e database ACS:

  • SQL Server 2019 con un aggiornamento cumulativo minimo 8 (CU8) o versione successiva come disponibile qui
  • SQL Server 2016 e gli aggiornamenti più recenti disponibili qui
  • SQL Server 2022 con un aggiornamento cumulativo minimo 11 (CU11) o versione successiva come disponibile qui
  • SQL Server 2019 con un aggiornamento cumulativo minimo 8 (CU8) o versione successiva come disponibile qui
  • SQL Server 2017 con l'aggiornamento disponibile più recente disponibile qui
  • SQL Server 2017 e aggiornamenti cumulativi come descritto qui
  • SQL Server 2016 e Service Pack come descritto qui

Le versioni seguenti di SQL Server Enterprise & edizione Standard sono supportate per un'installazione nuova o esistente di System Center 2016 - Operations Manager per ospitare reporting server, operativo, data warehouse e database ACS:

  • SQL Server 2016 e gli aggiornamenti più recenti disponibili qui
  • SQL Server 2014 e gli aggiornamenti più recenti disponibili qui
  • SQL Server 2012 e gli aggiornamenti più recenti disponibili qui

Driver di SQL Server

I driver OLE DB e ODBC DI SQL Server devono essere installati in tutti i server di gestione e nel server della console Web, poiché questi componenti si interfacciano direttamente con i database e questi driver consentono l'accesso a livello di API a SQL.

È consigliabile usare una connessione di SQL Server crittografata; in questo caso, è necessario installare le versioni più recenti dei driver SQL:

Altre informazioni sulla configurazione della crittografia della connessione SQL sono disponibili qui: Configurare sql Server motore di database per crittografare le connessioni

Se non si usano connessioni SQL crittografate, usare le versioni precedenti dei driver SQL che non applicano la crittografia:

Aggiornamenti di SQL Server

Per ognuno dei componenti di SQL Server seguenti che supportano un'infrastruttura di Operations Manager è necessaria la stessa versione principale di SQL Server:

  • Istanze del motore di database di SQL Server che ospitano uno qualsiasi dei database di Operations Manager, tra cui:
    • OperationManager
    • OperationManagerDW
    • Database SSRS ReportServer e ReportServerTempDB
  • Istanza di SQL Server Reporting Services (SSRS).

Modalità di autenticazione di SQL Server

Per impostazione predefinita, SQL opera in una configurazione di autenticazione in modalità mista. Tuttavia, Operations Manager usa solo autenticazione di Windows per comunicare con SQL Server. Se lasciato per impostazione predefinita, l'impostazione autenticazione in modalità mista SQL funzionerà comunque se nessun account locale ha il db_owner ruolo . Gli account locali con il db_owner ruolo sono noti per causare problemi con Operations Manager.

È consigliabile rimuovere il db_owner ruolo da tutti gli account locali prima di installare il prodotto e non aggiungere il db_owner ruolo ad alcun account locale dopo l'installazione.

Altre considerazioni

Altre considerazioni relative all'hardware e al software si applicano alla pianificazione della progettazione:

  • È consigliabile disporre di dischi SQL in formato file NTFS.
  • Al momento della creazione del database, è necessario disporre di almeno 1 GB di spazio libero su disco per il database operativo e del data warehouse. Tenere presente che l'utilizzo del disco dei database aumenterà notevolmente dopo l'installazione, assicurarsi di avere un sacco di spazio libero su disco al di sopra di questo requisito di base.
  • È richiesto .NET Framework 4.
  • .NET Framework 4.8 è supportato da Operations Manager 2022.
  • Reporting Server non è supportato in Windows Server Core.
  • L'impostazione delle regole di confronto di SQL Server deve essere uno dei tipi supportati, come descritto nella sezione Impostazione delle regole di confronto di SQL Server.
  • La ricerca full-text di SQL Server è necessaria per tutte le istanze del motore di database di SQL Server che ospitano uno qualsiasi dei database di Operations Manager.
  • Le opzioni di installazione di Windows Server (Server Core, Server with Desktop Experience e Nano Server) supportate dai componenti di database di Operations Manager sono basate sulle opzioni di installazione supportate da SQL Server.

Per altre informazioni, vedere la sezione Requisiti hardware e software nella documentazione relativa all'installazione e alla pianificazione di SQL Server qui: Pianificare un'installazione di SQL Server

Impostazione delle regole di confronto di SQL Server

Le regole di confronto di SQL Server e Windows seguenti sono supportate in System Center Operations Manager.

Nota

Per evitare problemi di compatibilità durante il confronto o la copia delle operazioni, è consigliabile usare le stesse regole di confronto per il database SQL e Operations Manager.

Regole di confronto di SQL Server

  • SQL_Latin1_General_CP1_CI_AS

Regole di confronto di Windows

  • Latin1_General_100_CI_AS
  • French_CI_AS
  • French_100_CI_AS
  • Cyrillic_General_CI_AS
  • Chinese_PRC_CI_AS
  • Chinese_Simplified_Pinyin_100_CI_AS
  • Chinese_Traditional_Stroke_Count_100_CI_AS
  • Japanese_CI_AS
  • Japanese_XJIS_100_CI_AS
  • Traditional_Spanish_CI_AS
  • Modern_Spanish_100_CI_AS
  • Latin1_General_CI_AS
  • Cyrillic_General_100_CI_AS
  • Korean_100_CI_AS
  • Czech_100_CI_AS
  • Hungarian_100_CI_AS
  • Polish_100_CI_AS
  • Finnish_Swedish_100_CI_AS

Se l'istanza di SQL Server non è configurata con una delle regole di confronto supportate elencate in precedenza, l'esecuzione di una nuova installazione di Operations Manager non riesce. Tuttavia, un aggiornamento sul posto viene completato correttamente.

Configurazione firewall

Operations Manager dipende da SQL Server per ospitare i relativi database e una piattaforma di report per analizzare e presentare dati operativi cronologici. I ruoli del server di gestione, delle operazioni e della console Web devono essere in grado di comunicare correttamente con SQL Server ed è importante comprendere il percorso di comunicazione e le porte per configurare correttamente l'ambiente.

Se si progetta una distribuzione distribuita che usa i gruppi di disponibilità SQL Always On, sono necessarie impostazioni di configurazione del firewall aggiuntive che devono essere incluse nella strategia di sicurezza del firewall.

La tabella seguente identifica le porte del firewall richieste da SQL Server per consentire ai server di gestione di comunicare con i database:

Scenario Porta Direzione Ruolo di Operations Manager
SQL Server che ospita i database di Operations Manager TCP 1433 * In entrata server di gestione e console Web (per Application Advisor e Application Diagnostics)
Servizio SQL Server Browser UDP 1434 In entrata server di gestione
Connessione amministrativa dedicata di SQL Server TCP 1434 In entrata server di gestione
Altre porte usate da SQL Server
- Chiamate di procedura remota Microsoft (MS RPC)
- Strumentazione gestione Windows (WMI)
- Microsoft Distributed Transaction Coordinator (MS DTC)		 TCP 135 In entrata server di gestione
Listener del gruppo di disponibilità AlwaysOn di SQL Server Porta configurata dall'amministratore In entrata server di gestione
SQL Server Reporting Services che ospita Operations Manager Reporting Server TCP 80 (impostazione predefinita)/443 (SSL) In entrata Server di gestione e Console operatore

Nota

Mentre TCP 1433 è la porta standard per l'istanza predefinita del motore di database, quando si crea un'istanza denominata in un'istanza autonoma di SQL Server o si è distribuito un gruppo di disponibilità SQL AlwaysOn, viene definita una porta personalizzata e deve essere documentata per riferimento in modo da configurare correttamente i firewall e immettere queste informazioni durante l'installazione.

Per una panoramica più dettagliata dei requisiti del firewall per SQL Server, vedere Configurare Windows Firewall per consentire l'accesso a SQL Server.

Considerazioni sulla capacità e sull'archiviazione

Database di Operations Manager

Il database di Operations Manager è un database di SQL Server che contiene tutti i dati necessari per Operations Manager per il monitoraggio giornaliero. Il ridimensionamento e la configurazione del server di database sono fondamentali per le prestazioni complessive del gruppo di gestione. La risorsa più critica usata dal database di Operations Manager è il sottosistema di archiviazione, ma anche la CPU e la RAM sono significative.

I fattori che influenzano il carico nel database di Operations Manager includono:

  • Frequenza di raccolta dati operativi.
    • La frequenza di raccolta dati operativi è influenzata da fattori quali il numero di Management Pack importati, il numero di agenti aggiunti e il tipo di computer monitorato. Ad esempio, un agente che monitora un computer desktop business critical raccoglie meno dati rispetto a un agente che monitora un server che esegue SQL Server con più database.
  • Frequenza delle modifiche dello spazio dell'istanza.
    • L'aggiornamento dei dati esistenti nel database di Operations Manager richiede un elevato utilizzo delle risorse rispetto alla scrittura di nuovi dati operativi. Inoltre, quando sono presenti modifiche ai dati dello spazio dell'istanza, i server di gestione devono eseguire più query al database per calcolare le modifiche alla configurazione e al gruppo. La frequenza di modifica dello spazio dell'istanza aumenta quando si importano nuovi Management Pack o si aggiungono nuovi agenti al gruppo di gestione.
  • Anche il numero di Console operatore e altre connessioni SDK in esecuzione contemporaneamente influisce sul carico sul database.
    • Ogni Console operatore legge i dati dal database di Operations Manager. L'esecuzione di query su questi dati utilizza potenzialmente grandi quantità di risorse di I/O di archiviazione, tempo CPU e RAM. Le console operatore che visualizzano grandi quantità di dati operativi nella visualizzazione eventi, visualizzazione stato, visualizzazione avvisi e dati sulle prestazioni tendono a causare il carico più elevato nel database.

Il database di Operations Manager è un'unica origine di errore per il gruppo di gestione, quindi può essere resa a disponibilità elevata usando configurazioni di failover supportate, ad esempio gruppi di disponibilità AlwaysOn di SQL Server o istanze del cluster di failover.

È possibile configurare e aggiornare i database di Operations Manager con un'installazione SQL Always-On esistente senza dover apportare modifiche dopo la configurazione.

Abilitare SQL Broker nel database di Operations Manager

System Center Operations Manager dipende da SQL Server Service Broker per implementare tutte le operazioni di attività. Se SQL Server Service Broker è disabilitato, tutte le operazioni di attività sono interessate. Il comportamento risultante può variare in base all'attività avviata. È quindi importante controllare lo stato di SQL Server Service Broker ogni volta che si osserva un comportamento imprevisto intorno a un'attività in System Center Operations Manager.

Per abilitare SQL Server Service Broker, seguire questa procedura:

  1. Eseguire la query SQL seguente per verificare se il broker è già abilitato, indicato da un risultato pari a 1 (uno) nel is_broker_enabled campo:

    SELECT is_broker_enabled FROM sys.databases WHERE name='OperationsManager'

  2. Se il valore visualizzato nel is_broker_enabled campo è 0 (zero), eseguire l'istruzione SQL seguente per abilitare il broker:

    ALTER DATABASE OperationsManager SET SINGLE_USER WITH ROLLBACK IMMEDIATE
ALTER DATABASE OperationsManager SET ENABLE_BROKER
ALTER DATABASE OperationsManager SET MULTI_USER

Database del data warehouse di Operations Manager

Nota

Il data warehouse di Operations Manager viene anche definito database "Data Warehouse di report" o semplicemente "Data Warehouse" in una documentazione.

System Center Operations Manager inserisce i dati nel data warehouse quasi in tempo reale, è importante avere una capacità sufficiente in questo server che supporta la scrittura di tutti i dati raccolti nel data warehouse. Come per il database di Operations Manager, la risorsa più critica nel data warehouse è il sottosistema di I/O di archiviazione. Nella maggior parte dei sistemi, i carichi nel data warehouse sono simili al database di Operations Manager, ma possono variare. Inoltre, il carico di lavoro inserito nel data warehouse tramite la creazione di report è diverso dal carico inserito nel database di Operations Manager dall'utilizzo della console operatore.

I fattori che influenzano il carico nel data warehouse includono:

  • Frequenza di raccolta dati operativi.
    • Il data warehouse esegue calcoli e archivia i dati aggregati, insieme a una quantità limitata di dati non elaborati, per consentire la creazione di report più efficienti. Di conseguenza, il costo di raccolta dei dati operativi nel data warehouse è leggermente superiore rispetto al database di Operations Manager. Tuttavia, questo costo è compensato dal costo di elaborazione ridotto dei dati di individuazione nel data warehouse rispetto al database di Operations Manager.
  • Numero di utenti di report simultanei o generazione di report pianificati.
    • Ogni utente di report può aggiungere un carico significativo nel sistema perché i report riepilogano spesso grandi volumi di dati. Le esigenze complessive di capacità sono influenzate dal numero di report eseguiti simultaneamente e dal tipo di report in esecuzione. I report che eseguono query su intervalli di date di grandi dimensioni o un numero elevato di oggetti richiedono risorse di sistema aggiuntive.

In base a questi fattori, esistono diverse procedure consigliate da considerare per il dimensionamento del data warehouse:

  • Scegliere un sottosistema di archiviazione appropriato.
    • Poiché il data warehouse è parte integrante del flusso di dati complessivo attraverso il gruppo di gestione, è importante scegliere un sottosistema di archiviazione appropriato per il data warehouse. Come per il database di Operations Manager, RAID 0 + 1 è spesso la scelta migliore. In generale, il sottosistema di archiviazione per il data warehouse deve essere simile al sottosistema di archiviazione per il database di Operations Manager e le linee guida applicabili al database di Operations Manager si applicano anche al data warehouse.
  • Prendere in considerazione il posizionamento appropriato dei log dei dati e dei log delle transazioni.
    • Per quanto riguarda il database di Operations Manager, la separazione dei dati SQL e dei log delle transazioni è spesso una scelta appropriata quando si aumenta il numero di agenti. Se sia il database di Operations Manager che il data warehouse si trovano nello stesso server e si desidera separare i dati e i log delle transazioni, è necessario inserire i log delle transazioni per il database di Operations Manager in un volume fisico separato e spindle del disco dal data warehouse per ricevere qualsiasi vantaggio. I file di dati per il database e il data warehouse di Operations Manager possono condividere lo stesso volume fisico purché il volume fornisca capacità adeguata e le prestazioni di I/O del disco non influiscano negativamente sulla funzionalità di monitoraggio e creazione di report.
  • Prendere in considerazione l'inserimento del data warehouse in un server separato dal database di Operations Manager.
    • Anche se le distribuzioni su scala ridotta possono spesso consolidare il database e il data warehouse di Operations Manager nello stesso server, è vantaggioso separarli man mano che si aumenta il numero di agenti e il volume dei dati operativi in ingresso. Quando il data warehouse e il server di report si trovano in un server separato dal database di Operations Manager, si riscontrano prestazioni migliori per la creazione di report.

Il database del data warehouse di Operations Manager è un'unica origine di errore per il gruppo di gestione, pertanto può essere resa a disponibilità elevata usando configurazioni di failover supportate, ad esempio gruppi di disponibilità AlwaysOn di SQL Server o istanze del cluster di failover.

SQL Server Always On

I gruppi di disponibilità AlwaysOn di SQL Server supportano gli ambienti di failover per un set discreto di database utente (database di disponibilità). Ogni set di database di disponibilità è ospitato in una replica di disponibilità.

Con System Center 2016 e versioni successive - Operations Manager, SQL Always On è preferibile rispetto al clustering di failover per offrire disponibilità elevata per i database. Tutti i database ad eccezione dell'installazione nativa di Reporting Services, che usa due database per separare l'archiviazione dati persistente dai requisiti di archiviazione temporanea, possono essere ospitati in un gruppo di disponibilità AlwaysOn.

Per configurare un gruppo di disponibilità, distribuire un cluster WSFC (Windows Server Failover Clustering) per ospitare la replica di disponibilità e abilitare Always On nei nodi del cluster. È quindi possibile aggiungere il database di SQL Server di Operations Manager come database di disponibilità.

Suggerimento

A partire da Operations Manager 2022, è possibile configurare e aggiornare i database di Operations Manager con un'installazione sql Always-On esistente senza la necessità di apportare modifiche dopo la configurazione.

Per configurare un gruppo di disponibilità, distribuire un cluster WSFC (Windows Server Failover Clustering) per ospitare la replica di disponibilità e abilitare Always On nei nodi del cluster. È quindi possibile aggiungere il database di SQL Server di Operations Manager come database di disponibilità.

Nota

Dopo aver distribuito Operations Manager nei nodi di SQL Server che partecipano a SQL Always On, per abilitare la sicurezza rigorosa di CLR, eseguire lo script SQL in ogni database di Operations Manager.

Stringa multisubnet

Operations Manager non supporta le parole chiave stringa di connessione (MultiSubnetFailover=True). Poiché un gruppo di disponibilità ha un nome di listener (noto come nome di rete o punto di accesso client in Gestione cluster WSFC) a seconda di più indirizzi IP di subnet diverse, ad esempio quando si esegue la distribuzione in una configurazione di failover tra siti, le richieste di connessione client dai server di gestione al listener del gruppo di disponibilità raggiungeranno un timeout di connessione.

L'approccio consigliato per ovviare a questa limitazione con i nodi del server del gruppo di disponibilità distribuiti in un ambiente con più subnet consiste nel:

  1. Impostare il nome di rete del listener del gruppo di disponibilità per registrare solo un singolo indirizzo IP attivo in DNS.
  2. Configurare il cluster per l'uso di un valore TTL basso per il record DNS registrato.

Queste impostazioni consentono un ripristino e una risoluzione più rapidi del nome del cluster con il nuovo indirizzo IP durante il failover in un nodo in una subnet diversa.

Eseguire i comandi di PowerShell seguenti in uno dei nodi SQL per modificare queste impostazioni:

Import-Module FailoverClusters
Get-ClusterResource "Cluster Name"|Set-ClusterParameter RegisterAllProvidersIP 0
Get-ClusterResource "Cluster Name"|Set-ClusterParameter HostRecordTTL 300
Stop-ClusterResource "Cluster Name"
Start-ClusterResource "Cluster Name"
Start-ClusterGroup "Cluster Name"

Se si usa Always On con un nome del listener, è necessario apportare anche queste modifiche di configurazione nel listener. Per altre informazioni sulla configurazione di un listener del gruppo di disponibilità, vedere la documentazione qui: Configurare il listener del gruppo di disponibilità - SQL Server AlwaysOn.

I comandi di PowerShell seguenti possono essere eseguiti nel nodo SQL che ospita attualmente il listener per modificarne le impostazioni:

Import-Module FailoverClusters
Get-ClusterResource <Listener Cluster Resource name> | Set-ClusterParameter RegisterAllProvidersIP 0
Get-ClusterResource <Listener Cluster Resource name> | Set-ClusterParameter HostRecordTTL 300
Stop-ClusterResource <Listener Cluster Resource name>
Start-ClusterResource <Listener Cluster Resource name>
Start-ClusterGroup <Listener Cluster Group name>

Quando per la disponibilità elevata viene usata un'istanza SQL in cluster o AlwaysOn, è necessario abilitare la funzionalità di ripristino automatico nei server di gestione per evitare il riavvio del servizio di accesso ai dati di Operations Manager ogni volta che si verifica un failover tra i nodi. Per informazioni sulla configurazione, vedere l'articolo della Knowledge Base seguente Il servizio di gestione di System Center smette di rispondere dopo che un'istanza di SQL Server diventa offline.

Ottimizzare SQL Server

Le esperienze di supporto hanno dimostrato che i problemi di prestazioni non sono in genere causati da un utilizzo elevato delle risorse (ovvero processore o memoria) con SQL Server stesso; piuttosto il problema è direttamente correlato alla configurazione del sottosistema di archiviazione. I colli di bottiglia delle prestazioni sono comunemente attribuiti a non seguire le indicazioni di configurazione consigliate con l'archiviazione di cui è stato effettuato il provisioning per l'istanza del database di SQL Server. Di seguito sono riportati alcuni esempi:

  • Allocazione insufficiente di spindle per i LUN per supportare i requisiti di I/O di Operations Manager.
  • Hosting dei log delle transazioni e dei file di database nello stesso volume. Questi due carichi di lavoro hanno caratteristiche di I/O e latenza diverse.
  • La configurazione di TempDB non è corretta in relazione al posizionamento, al ridimensionamento e così via.
  • Errore di allineamento della partizione del disco dei volumi che ospitano i log delle transazioni del database, i file di database e TempDB.
  • Ignorare la configurazione di base di SQL Server, ad esempio l'uso di AUTOGROW per i file di database e di log delle transazioni, l'impostazione MAXDOP per il parallelismo delle query, la creazione di più file di dati TempDB per core CPU e così via.

La configurazione dell'archiviazione è uno dei componenti critici di una distribuzione di SQL Server per Operations Manager. I server di database tendono a essere fortemente associati a operazioni di I/O dovute a un'attività rigorosa di lettura e scrittura del database e all'elaborazione del log delle transazioni. Il modello di comportamento di I/O di Operations Manager è in genere l'80% di scritture e il 20% di letture. Di conseguenza, una configurazione non corretta dei sottosistemi di I/O può portare a prestazioni e funzionamento non ottimali dei sistemi SQL Server e diventa evidente in Operations Manager.

È importante testare la progettazione di SQL Server eseguendo test della velocità effettiva del sottosistema I/O prima di distribuire SQL Server. Assicurarsi che questi test siano in grado di soddisfare i requisiti di I/O con una latenza accettabile. Usare l'utilità Diskspd per valutare la capacità di I/O del sottosistema di archiviazione che supporta SQL Server. L'articolo di blog seguente, creato da un membro del team di File Server nel gruppo di prodotti, fornisce indicazioni dettagliate e consigli su come eseguire test di stress usando questo strumento - DiskSpd, PowerShell e prestazioni di archiviazione: misurazione di operazioni di I/O, velocità effettiva e latenza per dischi locali e condivisioni file SMB.

Dimensioni unità di allocazione NTFS

L'allineamento del volume, comunemente definito allineamento del settore, deve essere eseguito nel file system (NTFS) ogni volta che un volume viene creato in un dispositivo RAID. L'errore può causare una riduzione significativa delle prestazioni ed è in genere il risultato di un errore di allineamento della partizione con limiti di unità di striping. Può anche causare un errore di allineamento della cache hardware, con conseguente utilizzo inefficiente della cache di matrici.

Quando si formatta la partizione usata per i file di dati di SQL Server, è consigliabile usare una dimensione di unità di allocazione di 64 KB ( ovvero 65.536 byte) per dati, log e TempDB. Tenere presente, tuttavia, che l'uso di dimensioni di unità di allocazione superiori a 4 KB comporta l'impossibilità di usare la compressione NTFS nel volume. Anche se SQL Server supporta i dati di sola lettura nei volumi compressi, non è consigliabile.

Riserva memoria

Nota

Gran parte delle informazioni contenute in questa sezione proviene da Jonathan Kehayias nel post di blog Quanto memoria ha effettivamente bisogno di SQL Server? (sqlskills.com).

Non è sempre facile identificare la quantità corretta di memoria fisica e processori da allocare per SQL Server a supporto di System Center Operations Manager (o per altri carichi di lavoro al di fuori di questo prodotto). Il calcolatore di ridimensionamento fornito dal gruppo di prodotti fornisce indicazioni basate sulla scalabilità del carico di lavoro, ma le raccomandazioni sono basate sui test eseguiti in un ambiente lab che potrebbe o meno allinearsi al carico di lavoro e alla configurazione effettivi.

SQL Server consente di configurare la quantità minima e massima di memoria che verrà riservata e usata dal processo. Per impostazione predefinita, SQL Server può modificare i requisiti di memoria in modo dinamico in base alle risorse di sistema disponibili. L'impostazione predefinita per min server memory è 0 e l'impostazione predefinita per max server memory è 2.147.483.647 MB.

I problemi relativi alle prestazioni e alla memoria possono verificarsi se non si imposta un valore appropriato per la memoria massima del server. Molti fattori influenzano la quantità di memoria da allocare a SQL Server per garantire che il sistema operativo possa supportare altri processi in esecuzione su tale sistema, ad esempio la scheda HBA, gli agenti di gestione e l'analisi in tempo reale antivirus. Se non è impostata memoria sufficiente, il sistema operativo e SQL eseguiranno la pagina su disco. Ciò può causare l'aumento dell'I/O del disco, riducendo ulteriormente le prestazioni e creando un effetto increspamento in cui diventa evidente in Operations Manager.

È consigliabile specificare almeno 4 GB di RAM per la memoria minima del server. Questa operazione deve essere eseguita per ogni nodo SQL che ospita uno dei database di Operations Manager (operativo, data warehouse, ACS).

Per la memoria massima del server, è consigliabile riservare inizialmente un totale di:

  • 1 GB di RAM per il sistema operativo
  • 1 GB di RAM ogni 4 GB di RAM installata (fino a 16 GB di RAM)
  • 1 GB di RAM per ogni 8 GB di RAM installata (oltre 16 GB di RAM)

Dopo aver impostato questi valori, monitorare il contatore Memory\Available MBytes in Windows per determinare se è possibile aumentare la memoria disponibile per SQL Server. Windows segnala che la memoria fisica disponibile è insufficiente a 96 MB, quindi idealmente il contatore non dovrebbe essere eseguito inferiore a circa 200-300 MB, per assicurarsi di avere un buffer. Per i server con 256 GB di RAM o versione successiva, assicurarsi che non venga eseguito inferiore a 1 GB.

Tenere presente che questi calcoli presuppongono che SQL Server sia in grado di usare tutta la memoria disponibile, a meno che non vengano modificati in modo da tenere conto di altre applicazioni. Prendere in considerazione i requisiti di memoria specifici per il sistema operativo, altre applicazioni, lo stack di thread di SQL Server e altri allocatori a più pagine. Una formula tipica è ((total system memory) – (memory for thread stack) – (OS memory requirements) – (memory for other applications) – (memory for multipage allocators)), dove la memoria per lo stack di thread = ((max worker threads) (stack size)). Le dimensioni dello stack sono di 512 KB per sistemi x86, 2 MB per sistemi x64 e 4 MB per i sistemi IA64 ed è possibile trovare il valore per max worker thread nella colonna max_worker_count di sys.dm_os_sys_info.

Queste considerazioni si applicano anche ai requisiti di memoria per l'esecuzione di SQL Server in una macchina virtuale. Poiché SQL Server è progettato per memorizzare nella cache i dati nel pool di buffer e usa la maggior quantità di memoria possibile, può essere difficile determinare la quantità ideale di RAM necessaria. Quando si riduce la memoria allocata a un'istanza di SQL Server, è possibile raggiungere un punto in cui l'allocazione di memoria inferiore viene scambiata per un accesso di I/O su disco superiore.

Per configurare la memoria di SQL Server in un ambiente di cui è stato eseguito il provisioning eccessivo, iniziare monitorando l'ambiente e le metriche delle prestazioni correnti, inclusi l'aspettativa di vita della pagina di Gestione buffer di SQL Server e le letture di pagina/sec e i valori lettura disco fisico/sec. Se l'ambiente ha memoria in eccesso, l'aspettativa di vita delle pagine aumenterà di un valore di uno al secondo senza ridurre il carico di lavoro, a causa della memorizzazione nella cache. Il valore della pagina di Gestione buffer di SQL Server sarà ridotto dopo l'aumento delle dimensioni della cache e le letture del disco fisico/sec rimarranno basse.

Dopo aver compreso la baseline dell'ambiente, è possibile ridurre la memoria massima del server di 1 GB, quindi vedere come influisce sui contatori delle prestazioni (dopo eventuali concessioni di scaricamento iniziale della cache). Se le metriche rimangono accettabili, ridurre di altri 1 GB, quindi eseguire di nuovo il monitoraggio, ripetendo come desiderato fino a quando non si determina una configurazione ideale.

Per altre informazioni, vedere Opzioni di configurazione della memoria del server.

Per altre informazioni, vedere Opzioni di configurazione della memoria del server.

Ottimizzare TempDB

Le dimensioni e il posizionamento fisico del database TempDB possono influire sulle prestazioni di Operations Manager. Ad esempio, se le dimensioni definite per TempDB sono troppo piccole, la parte del carico di elaborazione del sistema può essere caricata con tempDB di ridimensionamento automatico alle dimensioni necessarie per supportare il carico di lavoro ogni volta che si riavvia l'istanza di SQL Server. Per ottenere prestazioni ottimali di TempDB, è consigliabile usare la configurazione seguente per TempDB in un ambiente di produzione:

  • Impostare il modello di recupero di TempDB su SIMPLE.
    • Questo modello recupera automaticamente lo spazio di log per mantenere i requisiti di spazio ridotti.
  • Preallocare lo spazio per tutti i file di TempDB impostando le relative dimensioni su un valore adeguato per il carico di lavoro tipico dell'ambiente. Impedisce l'espansione troppo frequente di TempDB, che può influire sulle prestazioni. Il database TempDB può essere impostato su aumento automatico, ma deve essere usato per aumentare lo spazio su disco per le eccezioni non pianificate.
  • Creare tutti i file necessari per ottimizzare la larghezza di banda del disco.
    • L'uso di più file riduce la contesa di archiviazione TempDB e produce una maggiore scalabilità. Tuttavia, non creare troppi file perché può ridurre le prestazioni e aumentare il sovraccarico di gestione.
    • Come linea guida generale, creare un file di dati per ogni processore logico nel server (tenendo conto di eventuali impostazioni di affinity mask) e quindi regolare il numero di file verso l'alto o verso il basso in base alle esigenze.
    • In generale, se il numero di processori logici è minore o uguale a 8, usare un numero di file di dati pari al numero dei processori logici.
      • Se il numero di processori logici è maggiore di 8, usare otto file di dati e quindi, se la contesa continua, aumentare il numero di file di dati di più di 4 (fino al numero di processori logici) fino a quando la contesa non viene ridotta a livelli accettabili o apportare modifiche al carico di lavoro/codice.
      • Se la contesa non viene ridotta, potrebbe essere necessario aumentare il numero di file di dati.
  • Rendere ogni file di dati la stessa dimensione, consentendo prestazioni di riempimento proporzionali ottimali.
    • Il dimensionamento uguale dei file di dati è fondamentale perché l'algoritmo di riempimento proporzionale è basato sulle dimensioni dei file. Se i file di dati vengono creati con dimensioni diverse, l'algoritmo di riempimento proporzionale tenta di usare il file più grande per le allocazioni GAM invece di distribuire le allocazioni tra tutti i file, sconfiggendo così lo scopo di creare più file di dati.
  • Inserire il database TempDB in un sottosistema di I/O veloce usando unità ssd per ottenere prestazioni ottimali.
    • In presenza di molti dischi collegati direttamente, utilizzare lo striping del disco.
  • Posizionare il database TempDB in dischi diversi da quelli usati dai database utente.

Per configurare TempDB, è possibile eseguire la query seguente o modificarne le proprietà in Management Studio.

USE [TempDB]
GO
DBCC SHRINKFILE (N'tempdev' , 8)
GO
USE [master]
GO
ALTER DATABASE [TempDB] MODIFY FILE ( NAME = N'tempdev', NEWNAME = N'TempDB', SIZE = 2097152KB , FILEGROWTH = 512MB )
GO
ALTER DATABASE [TempDB] ADD FILE ( NAME = N'TempDB2', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\TempDB2.mdf' , SIZE = 2097152KB , FILEGROWTH = 512MB )
GO

Eseguire la query SELECT * from sys.sysprocesses T-SQL per rilevare la contesa di allocazione delle pagine per il database TempDB. Nell'output della tabella di sistema la risorsa di attesa può essere visualizzata come "2:1:1" (pagina PFS) o "2:1:3" (pagina Mappa allocazione globale condivisa). A seconda del grado di contesa, questa impostazione potrebbe causare la mancata risposta di SQL Server per brevi periodi. Un altro approccio consiste nell'esaminare le viste a gestione dinamica [sys.dm_exec_request o sys.dm_os_waiting_tasks]. I risultati mostrano che queste richieste o attività sono in attesa di risorse TempDB e hanno valori simili come evidenziato in precedenza quando si esegue la sys.sysprocesses query.

Se le raccomandazioni precedenti non riducono significativamente la contesa di allocazione e la contesa si trova nelle pagine SGAM, implementare il flag -T1118 di traccia nei parametri di avvio per SQL Server in modo che il flag di traccia rimanga attivo anche dopo il riciclo di SQL Server. In questo flag di traccia, SQL Server alloca extent completi a ogni oggetto di database, eliminando così la contesa nelle pagine SGAM.

Nota

Questo flag di traccia influisce su ogni database nell'istanza di SQL Server.

Grado massimo di parallelismo

Suggerimento

Per le procedure consigliate e le raccomandazioni più recenti del team di SQL Server, vedere la documentazione qui: Impostare l'opzione max degree of parallelism per ottenere prestazioni ottimali

La configurazione predefinita di SQL Server per distribuzioni di piccole e medie dimensioni di Operations Manager è adeguata per la maggior parte delle esigenze. Tuttavia, quando il carico di lavoro del gruppo di gestione aumenta verso l'alto verso uno scenario di classe aziendale (in genere 2.000 sistemi gestiti dall'agente e una configurazione di monitoraggio avanzata, che include il monitoraggio a livello di servizio con transazioni sintetiche avanzate, monitoraggio dei dispositivi di rete, multipiattaforma e così via) è necessario ottimizzare la configurazione di SQL Server descritta in questa sezione del documento. Un'opzione di configurazione non illustrata nelle linee guida precedenti è MAXDOP.

L'opzione di configurazione max degree of parallelism (MAXDOP) di Microsoft SQL Server controlla il numero di processori usati per l'esecuzione di una query in un piano parallelo. Questa opzione determina le risorse di calcolo e thread usate per gli operatori del piano di query che eseguono il lavoro in parallelo. A seconda che SQL Server sia configurato in un computer SMP (Symmetric MultiProcessing), in un computer NUMA (NonUniform Memory Access) o in processori abilitati per l'hyperthreading, è necessario configurare l'opzione max degree of parallelism in modo appropriato.

Quando SQL Server viene eseguito in un computer con più microprocessori o CPU, rileva il miglior grado di parallelismo, ovvero il numero di processori impiegati per eseguire una singola istruzione, per ogni esecuzione di piano parallelo. Per impostazione predefinita, il valore di questa opzione è 0, che consente a SQL Server di determinare il grado massimo di parallelismo.

Le stored procedure e le query predefinite in Operations Manager in relazione al database operativo, al data warehouse e anche al database di controllo non includono l'opzione MAXDOP, perché non esiste alcun modo durante l'installazione per eseguire query in modo dinamico sul numero di processori presentati al sistema operativo, né tenta di impostare come hardcoded il valore per questa impostazione, che potrebbe avere conseguenze negative quando viene eseguita la query.

Nota

L'opzione di configurazione max degree of parallelism non limita il numero di processori usati da SQL Server. Per configurare il numero di processori usati da SQL Server, usare l'opzione di configurazione affinity mask.

  • Per i server che usano più di otto processori, usare la configurazione seguente: MAXDOP=8

  • Per i server che usano otto o meno processori, usare la configurazione seguente: MAXDOP=0 a N

    Suggerimento

    In questa configurazione rappresenta N il numero di processori.

  • Per i server con NUMA configurato, MAXDOP non deve superare il numero di CPU assegnate a ogni nodo NUMA.

  • Per i server con hyperthreading abilitato, il valore MAXDOP non deve superare il numero di processori fisici.

  • Per i server con NUMA configurato e hyperthreading abilitato, il valore MAXDOP non deve superare il numero di processori fisici per ogni nodo NUMA.

È possibile monitorare il numero di ruoli di lavoro paralleli eseguendo query su select * from sys.dm_os_tasks.

In questo esempio, la configurazione hardware del server era un HP Blade G6 con 24 processori core e 196 GB di RAM. L'istanza che ospita il database di Operations Manager ha un'impostazione MAXMEM di 64 GB. Dopo aver eseguito le ottimizzazioni suggerite in questa sezione, le prestazioni sono migliorate. Tuttavia, un collo di bottiglia del parallelismo di query è ancora persistente. Dopo aver testato valori diversi, le prestazioni ottimali sono state trovate impostando MAXDOP=4.

Dimensionamento iniziale del database

Il tentativo di stimare la crescita futura dei database di Operations Manager, in particolare i database operativi e del data warehouse, entro i primi mesi dalla distribuzione non è un semplice esercizio. Anche se l'helper di ridimensionamento di Operations Manager è ragionevole nella stima della potenziale crescita in base alla formula derivata dal gruppo di prodotti dai test in laboratorio, non tiene conto di diversi fattori, che possono influenzare la crescita a breve termine rispetto a lungo termine.

Le dimensioni iniziali del database, come suggerito dall'helper di ridimensionamento, devono essere allocate a una dimensione stimata per ridurre la frammentazione e il sovraccarico corrispondente, che può essere specificato in fase di configurazione per i database operativi e del data warehouse. Se durante l'installazione non è disponibile spazio di archiviazione sufficiente, i database possono essere espansi in un secondo momento usando SQL Management Studio e quindi reindicizzazione successivamente per deframmentare e ottimizzare di conseguenza. Questa raccomandazione si applica anche al database ACS.

Il monitoraggio proattivo della crescita del database operativo e del data warehouse deve essere eseguito su un ciclo giornaliero o settimanale. Ciò è necessario per identificare gli speroni di crescita imprevisti e significativi e iniziare la risoluzione dei problemi per determinare la causalità, se da un bug in un flusso di lavoro del Management Pack (ovvero regola di individuazione, regola di individuazione, regola di raccolta di eventi o monitoraggio o regola di monitoraggio o avviso) o altro sintomo con un Management Pack che non è stato identificato durante la fase di test e controllo della qualità del processo di gestione del rilascio.

Aumento automatico del database

Quando le dimensioni del file di database riservati diventano complete, SQL Server può aumentare automaticamente le dimensioni di una percentuale o di un importo fisso. Inoltre, è possibile configurare una dimensione massima del database per evitare di riempire tutto lo spazio disponibile su disco. Per impostazione predefinita, il database di Operations Manager non è configurato con l'aumento automatico abilitato; solo i database data warehouse e ACS sono.

Si basano solo sull'aumento automatico come emergenza per una crescita imprevista. L'aumento automatico comporta una riduzione delle prestazioni da considerare quando si tratta di un database altamente transazionale. Le sanzioni per le prestazioni includono:

  • Se non si specifica un incremento di crescita appropriato, la frammentazione del file di log o del database può verificarsi.
  • Se si esegue una transazione che richiede più spazio di log rispetto a quello disponibile e l'aumento automatico è abilitato per il log delle transazioni del database, il tempo necessario per il completamento della transazione includerà il tempo necessario per aumentare il log delle transazioni in base all'importo configurato.
  • Se si esegue una transazione di grandi dimensioni che richiede l'aumento del log, anche altre transazioni che richiedono una scrittura nel log delle transazioni dovranno attendere il completamento dell'operazione di aumento.

Se le opzioni autogrow e autoshrink sono combinate, questo può creare un sovraccarico non necessario. Assicurarsi che le soglie che attivano le operazioni di aumento e riduzione delle dimensioni non causino modifiche frequenti delle dimensioni. Ad esempio, è possibile eseguire una transazione che causa l'aumento del log delle transazioni di 100 MB al momento del commit; qualche tempo dopo l'avvio della compattazione automatica e compatta il log delle transazioni di 100 MB. Quindi si esegue la stessa transazione e il log delle transazioni aumenta di nuovo di 100 MB. In questo esempio si crea un sovraccarico non necessario e si crea potenzialmente la frammentazione del file di log, che può influire negativamente sulle prestazioni.

Configurare attentamente queste due impostazioni. La configurazione specifica dipende realmente dall'ambiente in uso. Per ridurre la frammentazione del disco, è consigliabile aumentare le dimensioni del database in base a un importo fisso. Vedere, ad esempio, la figura seguente, in cui il database è configurato per aumentare di 1.024 MB ogni volta che è necessaria l'aumento automatico.

Criteri di failover del cluster

Windows Server Failover Clustering è una piattaforma a disponibilità elevata che monitora costantemente le connessioni di rete e l'integrità dei nodi in un cluster. Se un nodo non è raggiungibile in rete, viene eseguita un'azione di ripristino per ripristinare e portare online applicazioni e servizi in un altro nodo del cluster. Le impostazioni predefinite predefinite sono ottimizzate per gli errori in cui si verifica una perdita completa di un server, che è considerato un errore "difficile". Si tratta di scenari di errore irreversibili, ad esempio l'errore dell'hardware o dell'alimentazione non irreversibile. In queste situazioni, il server viene perso e l'obiettivo è che il clustering di failover rilevi rapidamente la perdita del server e si ripristini rapidamente in un altro server nel cluster. Per eseguire questo recupero rapido da errori rigidi, le impostazioni predefinite per il monitoraggio dell'integrità del cluster sono piuttosto aggressive. Tuttavia, sono completamente configurabili per consentire flessibilità per diversi scenari.

Queste impostazioni predefinite offrono il comportamento migliore per la maggior parte dei clienti; Tuttavia, man mano che i cluster sono estesi da pollici a chilometri di distanza, il cluster può diventare esposto a più e potenzialmente inaffidabile componenti di rete tra i nodi. Un altro fattore è che la qualità dei server di materie prime è in costante aumento, abbinata alla resilienza aumentata tramite componenti ridondanti (ad esempio alimentatori duali, raggruppamenti NIC e I/O multi-percorso), il numero di errori hardware non ignorati può essere potenzialmente piuttosto raro. Poiché gli errori rigidi possono essere meno frequenti, alcuni clienti potrebbero voler ottimizzare il cluster per gli errori temporanei, in cui il cluster è più resiliente a brevi errori di rete tra i nodi. Aumentando le soglie di errore predefinite, è possibile ridurre la sensibilità a brevi problemi di rete che durano un breve periodo di tempo.

È importante comprendere che non esiste una risposta corretta in questo caso e l'impostazione ottimizzata può variare in base ai requisiti aziendali e ai contratti di servizio specifici.

Virtualizzazione di SQL Server

Negli ambienti virtuali, per motivi di prestazioni, è consigliabile archiviare il database operativo e il database del data warehouse in una risorsa di archiviazione collegata diretta e non in un disco virtuale. È possibile usare l'utilità helper di ridimensionamento di Operations Manager rilasciata per Operations Manager 2012 per stimare le operazioni di I/O al secondo necessarie e testare lo stress dei dischi dati da verificare. Le prestazioni di archiviazione possono essere testate con l'utilità DiskSpd. Vedere anche Supporto per la virtualizzazione di Operations Manager per altre indicazioni sull'ambiente Operations Manager virtualizzato.

Modello Always On e ripristino

Sebbene non sia strettamente un'ottimizzazione, una considerazione importante relativa al gruppo di disponibilità AlwaysOn è il fatto che, per impostazione predefinita, questa funzionalità richiede che i database siano impostati nel modello di recupero "Completo". Ciò significa che i log delle transazioni non vengono mai eliminati finché non viene eseguito un backup completo o solo il log delle transazioni. Per questo motivo, una strategia di backup non è facoltativa, ma una parte obbligatoria della progettazione AlwaysOn per i database di Operations Manager. In caso contrario, con il tempo, i dischi contenenti i log delle transazioni si riempiono.

Una strategia di backup deve tenere conto dei dettagli dell'ambiente. Nella tabella seguente viene fornita una pianificazione di backup tipica.

Tipo di backup Programmazione
Solo log delle transazioni Ogni ora
Completo Settimanale, domenica alle 3:00

Ottimizzazione di SQL Server Reporting Services

L'istanza di Reporting Services funge da proxy per l'accesso ai dati nel database del data warehouse. Genera e visualizza report basati su modelli archiviati all'interno dei Management Pack.

Il ruolo Report di Operations Manager non può essere installato in modalità side-by-side con una versione precedente del ruolo Reporting e deve essere installato solo in modalità nativa (la modalità integrata SharePoint non è supportata).

Dietro le quinte di Reporting Services, è presente un'istanza del database di SQL Server che ospita i database ReportServer e ReportServerTempDB. Si applicano raccomandazioni generali relative all'ottimizzazione delle prestazioni di questa istanza.

Nota

Da SQL Server Reporting Services (SSRS) 2017 versione 14.0.600.1274 e successive, le impostazioni di sicurezza predefinite non consentono il caricamento delle estensioni delle risorse. Ciò comporta eccezioni ResourceFileFormatNotAllowedException in Operations Manager durante la distribuzione dei componenti di report.

Per risolvere il problema:

  1. Aprire SQL Management Studio.
  2. Connettersi all'istanza di Reporting Services.
  3. Fare clic con il pulsante destro del mouse sull'istanza del server nella finestra Esplora oggetti.
  4. Selezionare Proprietà.
  5. Selezionare Avanzate sulla barra laterale sinistra.
  6. Aggiungere *.* all'elenco per AllowedResourceExtensionsForUpload.

In alternativa, è possibile aggiungere l'elenco completo delle estensioni per la creazione di report di Operations Manager all'elenco consenti in SSRS. L'elenco è descritto in "Risoluzione 2" qui: i report di Operations Manager non riescono a distribuire

Passaggi successivi

Per informazioni su come configurare l'hosting del data warehouse (reporting) dietro un firewall, vedere Connettere il data warehouse (reporting) in un firewall.